A final solution. (Was Re: kernel-2.2.1-undefined references.)

[Paul Derbyshire <pderbysh at usa dot net>]

>In particular, there are two kinds of "inline" in the kernel.  There's
>the "oh, I'd like to get this inlined" kind of inline, and there's the
>"consider this a macro" kind of inline. 

Uh... it kind of occurs to me that perhaps the simplest solution is just to
actually use a macro there? Then you can be damn sure it will inline,
because the preprocessor will have done it before egcs ever gets to see
your sources. :-)

>There's another class of "inline" usage, though - the "use as macro"
>class, because inline functions are often a _lot_ more readable than
>macros are, and you get tons of other advantages (the compiler does the
>argument copy so you don't have side effect problems, and often most
>importantly you get argument type-checking with good error messages with
>inline functions that you wouldn't get with a macro).  Those "use as a
>macro" inlines are marked, for the edification of gcc, as "extern
>inline". 

Ah. I see your point about inline versus actual macros. Maybe the solution
is this. First, 'extern inline' loses special significance, particularly
because of the standard likely covering the usage soon. On the other hand,
GCC can add __attribute__ ((always)) as an extension that will force
inlining of the function under well-determined conditions, specifically,
that it is not recursive. (The same rule that governs whether a macro
"inline function" will work properly.)
That leaves the sticky issue of taking addresses. An ordinary pointer to
function address taking can just force "exlining" a copy as a normal
function whose address will be used for pointers to functions (what is
presumably already done with plain-jane "inline" when it is inlined but the
function address is used). GCC can also perhaps try to optimize by
replacing function invocations through pointers with inline functions if a)
the function that will be invoked is known at compile time and b) it is
inline.
As for taking the address of a label in an inline function and using it,
this is trickier.
1: If the label will be encountered and then a goto is used on it,
   the compiler could use setjmp/longjmp to do it, thereby making
   sure thre goto goes to the correct inlined version.
2: Otherwise, it is trickier. One possibility is to exline an
   instance as a normal function and use the address of the label in
   that copy.
3: To dodge the ambiguous address problem altogether when only one
   instance will be inlined anyways, add an __attribute__ ((once)),
   and have the compiler inevitably inline the function (if
   nonrecursive) the first time it sees it. If it sees a second
   invocation, that's an error. Otherwise, label addresses
   unambiguously refer to the one instance.
4: An __attribute__ ((always)) or __attribute__ ((once)) that is
   recursive or otherwise uninlinable generates an error, regardless
   of -Winline.

Now, does this look like it'll make everybody happy?


>Guess what? A lot of them _used_ to be "static inline", because "static
>inline" is safer (it works as expected in the presense of the address-of
>operator, and yes, if the compiler refuses to inline the thing because
>it's not optimizing, it will still create the function for you).  Most
>of them were _changed_ to "extern inline" mostly due to the gcc
>documentation.

Have you tried changing them back to see if everything works perfectly?

>The ones that were bitten by the egcs bug (let's just be honest and call
>it what it really was) were so small that it would have been completely
>unreasonable for any good compiler to not inline them.  They were
>essentially two assignments and a copy, they just happened to have the
>address-of-label thing in some debugging code (because all other gcc
>methods of getting the current PC have been buggy at various points). 

The address-of-label is just used to generate displayed information? That
simplifies things a lot. If the address is only taken right at the label
itself, then it seems reasonable to make an inline __attribute__ ((always))
label and label address situation work like this:

-- The address-of-label operator can be invoked on the label only
   inside the function.
-- Then, it refers to the specific instance in the same inlined copy
   with the address operator.
-- Other uses are an error.
-- This can be implemented by making inlined functions with
   __attribute__ ((always)) and labels generate a different label
   symbol according to some mangling scheme for each instance, and
   the address-of refer to the appropriate mangled symbol when used
   legally.
-- The documentation can be made to reflect the details of this and
   of the circumstances for its legality.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|