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

[Zack Weinberg <zack at rabi dot columbia dot edu>]

On Fri, 12 Feb 1999 17:53:50 -0800 (PST), Linus Torvalds wrote:
>
>
>On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>>
>> Getting them to fix __builtin_return_address would be even better since
>> your code is (to put it bluntly) a kluge to get around a wart in GCC to
>> begin with. But my suggestions sure look doable...I'm not exactly sporting
>> a PhD in compiler theory, but 15 years of programming experience must count
>> for something =)
>
>Well, __builtin_return_address() has actually worked for a longish time.
>
>That's kind of the secondary problem: I'd love to track new releases and
>use new features when they come out, but I can't. Even if _I_ switch to a
>new compiler, few other people will, and then I get bug-reports with the
>old stuff - reports that are useless because the data they report is just
>bogus. 

In this particular case, you could use conditional compilation based
on __GNUC_MINOR__.  All the compilers that miscompile the
address-of-label hack do __builtin_return_address correctly, as I
understand it.

>The problem for me is that if I really have to create duplicates of all
>"extern inline" functions, the while thing is completely useless to me. It
>does _not_ act "almost as a macro" any more, it acts almost completely
>differently. 

I don't think you have to do that.  You can carry on using "extern
inline" as you have been.  If there's no other definition of a
particular function and gcc fails to inline it, you'll get a link
error, and then you can track down why that particular function
doesn't inline and tweak it or submit bugreports.

Or you can isolate the inline functions in their own header file, and
have a separate C file that just does

#define inline /* nothing */
#include <linux/inlinefuns.h>

No code duplication, and if all the inlines went through, the linker
will throw away the unnecessary object module.

zw