Return to the Press page

LWN.net Weekly Edition for May 16, 2013

PostgreSQL 9.3 beta: Federated databases and more

LWN.net Weekly Edition for May 9, 2013

(Nearly) full tickless operation in 3.10

Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

GCC hacks in the Linux kernel (developerWorks)

[Posted November 25, 2008 by ris]

IBM developerWorks looks at several special capabilities of the GNU Compiler Collection (GCC) suite built into the Linux kernel. "GCC and Linux are a great pair. Although they are independent pieces of software, Linux is totally dependent on GCC to enable it on new architectures. Linux further exploits features in GCC, called extensions, for greater functionality and optimization. This article explores many of these important extensions and shows you how they're used within the Linux kernel."

(Log in to post comments)

Posted Nov 25, 2008 22:33 UTC (Tue) by nix (subscriber, #2304) [Link]

Hm.

No mention of __builtin_return_address()'s nonportability when called with
a nonzero argument.

No mention of the statement expression extension, used in 575 places in
include/ alone, including in things as critical as WARN_ON()...

... oh, and your description is wrong. I boggled at first: 'GCC is built
into the Linux kernel? Since when?'

In fact it's looking at how several *language extensions* originated by
GCC are *used* by the Linux kernel. (Once we could have said that these
were GCC-specific, but several compilers support e.g. at least some
function and variable attributes now. I don't know if anyone else has
dared implement the statement expression extension :) )

GCC concepts built into GNU/Linux's kernel

Posted Nov 25, 2008 23:03 UTC (Tue) by coriordan (guest, #7544) [Link]

Trust a compiler critic to get sematic!

The kernel is surely written (built) with GCC capabilities in mind, so I wouldn't see the intro is wrong.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 7:18 UTC (Wed) by adobriyan (guest, #30858) [Link]

> No mention of the statement expression extension, used in 575 places in
> include/ alone, including in things as critical as WARN_ON()...

Regardless of article, most of these usages are completely unneeded and can
be accomplished with standard C without any loss of readability.

How cheap is ({ use for compiler?

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 8:48 UTC (Wed) by jamesh (guest, #1159) [Link]

How would you implement the max() macro given in the article using standard C? Remember that the implementation must satisfy:

Must be usable in expression context.
Only evaluates its arguments once.
Requires that both of its arguments are of the same type (i.e. no implicit casts).

While you can get the first and second from using a function, it won't help with the third. This is a problem in code that makes use of both signed and unsigned integers (as the kernel does).

While the macro body might be less readable than a simpler implementation, it does eliminate a whole class of error in use of the macro.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 10:20 UTC (Wed) by adobriyan (guest, #30858) [Link]

> How would you implement the max() macro given in the article using standard C?

I said most, not all.

Only a half of max() neatness is ({, the other is typeof.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 10:38 UTC (Wed) by rvfh (subscriber, #31018) [Link]

So that stuff basically brings polymorphism to C? Is that it?
That would be a nice extension to the language... instead of having abs, labs llabs fabs fabsf fabsl and I don't know what else...

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 27, 2008 5:12 UTC (Thu) by jamesh (guest, #1159) [Link]

My point was that without the statement expression, you couldn't do the other neat things that macro does.

Defining the local variables to avoid multiple evaluation requires statements. Using typeof() requires that the arguments are still in scope. Using the result in an expression requires that the macro expands to an expression.

The usual standard C trick of bracketing code with "do { ... } while (0)" gives you the first two but not the last.

If the C extensions provided no benefits or didn't improve readability, the kernel developers probably wouldn't be using them.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 20:20 UTC (Wed) by nix (subscriber, #2304) [Link]

({...}) is as cheap as any other block.

(The other questions have been answered well by other people.)

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 25, 2008 23:03 UTC (Tue) by berndp (guest, #52035) [Link]

Perhaps the author looks on to Intels icc which is also assumed to compile the Kernel.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 25, 2008 23:38 UTC (Tue) by nix (subscriber, #2304) [Link]

icc supports a number of GCC attributes at least and actually goes so far
as to #define __GNUC__.

(But the intro isn't 'wrong': after a day reviewing awful
contractor-written code I was being too picky. The intro is, ahem, perhaps
somehwat confusing.)

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 8:51 UTC (Wed) by rvfh (subscriber, #31018) [Link]

I had to read it twice too, had the same reaction as you first time: "What? GCC is built into the kernel???"

And I have given up reading contractor code for some time :-) I was reading Klockwork reports though...

BTW, is there a correct alternative (maybe lint?) to Klockwork that would be free/libre?

GCC hacks in the Linux kernel (developerWorks)

Posted Dec 1, 2008 3:56 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

True, it doesn't say GCC is built into the kernel, but it says something just as false: certain capabilities of GCC are built into the kernel. These capabilities do not exist in the kernel. The kernel isn't capable of compiling C at all.

I'm sure what the author had in mind was that _dependency_ on these GCC capabilities is built into the kernel.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 13:40 UTC (Wed) by MisterIO (guest, #36192) [Link]

It could have explained things a bit more, like for example the fact that "(void) (&_min1 == &_min2);" in min is there to give you a warning if the two variables are of different type and an explicit cast is not used.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 19:18 UTC (Wed) by iabervon (subscriber, #722) [Link]

The Linux kernel actually has quite a lot of macros with statements that don't generate any code but give errors when the macro is misused. My favorite is the typesafe callback code that doesn't care what type your data pointer points to, but does give you type errors if the function and data don't match.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 22:05 UTC (Wed) by MisterIO (guest, #36192) [Link]

Do you mean like this? :

#define check_callback_type(f,x) (sizeof((0 ? (f)(x) : (void)0), 0))

(from Al Viro's code)

This one, like other similar constructs, doesn't give you an error, but a warning. But I agree, it's very interesting.

GCC hacks in the Linux kernel (developerWorks)

Posted Nov 26, 2008 22:17 UTC (Wed) by iabervon (subscriber, #722) [Link]

Yeah, that's what I was thinking. It gives whatever error or message you'd get from calling the function directly in your code, but does it where you're going to lose the type information.