lkml.org 
[lkml]   [2004]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Is extern inline -> static inline OK?
Richard Henderson wrote:
> On Thu, Aug 05, 2004 at 05:39:07PM -0700, Tim Bird wrote:
>>Under what conditions is it NOT OK to convert "extern inline"
>>to "static inline"?
>
> When... I arrange for an external version to exist.

Richard - thanks for responding.

As you probably know, many people use extern inline
incorrectly in the kernel. Your construction appears
correct.

> ... Grep for EXTERN_INLINE in arch/alpha/kernel to see how it is
> used. If you can't figure it out, don't try to change anything.

I can see how it is used, but I can only guess the "why".
The only comment I can find about this usage is:
/* Do not touch, this should *NOT* be static inline */

There are a few different reasons someone might use
extern inline rather than static inline. Some affect
code correctness and some don't. Based on the strength
of the wording in your comment, I would guess that
the related code would suffer code correctness issues if
changed. However just examining the EXTERN_INLINE usage
itself did not reveal where the code would be incorrect
if static inline were used.

One type of usage which affects code correctness is
when the extern function definition differs from the
inline function definition. This type of usage of
"extern inline" is just plain wrong, since it RELIES
on the compiler to use a particular version of the
function (either the extern one or the inline one),
and the compiler is supposed to be free to make this
choice. This does not appear to be the case with your
code, since your construct uses the same source code
to create the extern functions as the extern inline
definitions. (But maybe I missed something.)

Other reasons for using extern inline are to minimize
code footprint by avoiding extra function copies in
different compilation units, and to increase cache hotness
by reusing the same code, when the compiler decides to not
inline a function. This last benefit is usually unlikely,
since uninlined code in the same compilation unit as the
currently executing code is much more likely to be
in-cache than uninlined code in some other compilation
unit.

Finally, another reason for using extern inline is to
avoid pointer comparison mismatch for function pointers
to uninlined functions.

In any event, it is difficult to tell what incorrectness
is (presumably) introduced in the alpha code by
using 'static inline' vs. 'extern inline', for the functions
so designated. Maybe you have specific code that breaks,
or maybe you just saw broken behaviour with the code compiled
differently.

If you could indicate WHY the alpha code must be 'extern inline',
it might be helpful to me, and instructive for others who
need to be educated on this same issue.
1) have different definitions for functions with same name
2) avoid wasting space with multiple function copies
3) increased instruction cache effectiveness
4) function pointers comparisons
5) some other reason I still don't understand

If anyone else can tell me if they are aware of cases of either
1) or 5) for other uses of 'extern inline' in the kernel, that
would be helpful.

BTW - I'm trying to figure this out because an instrumentation
system I'm working with uses gcc's -finstrument-functions, which
doesn't deal well with extern inlines that don't really have extern
definitions. I'm trying to get a grip on which 'extern inlines' it's
OK to change, and which aren't, and how to deal with the ones which
shouldn't be changed.

Thanks,

=============================
Tim Bird
Architecture Group Co-Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
E-mail: tim.bird@am.sony.com
=============================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.077 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site