understanding c preprocessor directives...

Quote:

---

Originally Posted by Elysia

The kernel is slow and they realize there's a much faster compiler out there that has recently been released?

---

Yeah, I know that you're just giving a worst case scenario... but I think that it really is unlikely. If there was a compiler that was much better at optimisation, they would probably help GCC implement the ground breaking optimisation techniques involved, perhaps even by merging code from that compiler, if possible. If that compiler was not Free/Open Source Software, it would not even be considered anyway, no matter how good it was (especially after the affair with Bitkeeper, a proprietary version control system).

Of course, GCC is prohibited from introducing particular forms of register allocation, due to commercial companies holding patents in that area. I'm sure some other register allocation can be used instead, and with identical effect.

There is also a dramatical performance difference between gcc in x86 and some other gcc implementations (when I compared gcc 2.x with a commercial alternative on AMD 29K, gcc 2.x generated roughly 40-50% more instructions - and in 29K, 40-50% more instructions mean 40-50% longer execution, since all instructions are "equal").

--
Mats

Quote:

---

Originally Posted by matsp

Actually, double underscore symbols are reserved for the compiler implementation, so techncially, that is "undefined behaviour" and can cause breakages - but I doubt that gcc will ever use those symbol names, and and since gcc is the only compiler used to compile the Linux kernel (which my guess is that these macros come from, more specifically the kernel loadable module section). Of course, the likelyhood of that actually happening is probably low.

And to explain a bit further:
__atrribute_used__ tells the compiler that it should not warn about unused variables or functions, even if the compiler doesn't think it is use.

The __attribute__((__section__(".initcall6.init"))) part tells the compiler to put this symbol in a special section. In particular ".initcallX.init" is a special set of sections that are processed by the system loader. The entire content of initcallX.init is assumed to be function pointers, and the system loader will call all those functions in the order they appear, starting with the lowest X.

--
Mats

---

Hi again!
Reading again and trying to understand better your answer I pointed my browser to http://gcc.gnu.org/onlinedocs/gcc/
I didn't find __attribute_used__ there but your explaination is clear so it doesn't matter..
About the section attribute, I just wonder if by "section" it is meant one of the sections of the executable file which is generated and which (in the case this executable is in ELF format, and this is the case in Linux) can be read with the help of readelf and objdump? In fact, the gcc doc says that the attribute "section" forces the compiler to place the corresponding code in a specific "section" which is different by the default "text"... Did I understand correctly?

Another question: what about the other names starting by "__".. (eg __initcall...)? Where could I find further documentation to understand what is the logic behind this "__"?

thanks again! :) bye

To start from the back: __ is just a couple of "letters" in an identifier. Identifiers can start with A-Za-z_ and then continue with an arbitrary number of the same or digits. One could choose XX instead of __. And as I stated earlier, __ is actually reserved to be used by the compiler implementation for implementation specific symbols. There is no "logic behind" this other than "if we start with two rather unusual 'letters', then the symbol is less likely to have the same name as something else".

Yes, sections are what you find in an ELF file, where ".text" is the common section for code, ".data" the common section for variables.

--
Mats