gcc 3.1 breaks wchan
PATCH 1/1 gcc 3.1 breaks wchan
Hi,
I noticed on a ppc64 kernel compiled with gcc 3.1 that context_switch was left out of line. It ended up outside of the scheduling_functions_start_here/end_here placeholders which breaks wchan.
This is one place where we require the code to be inline, so we should use extern.
Anton
kernel/sched.c +2 -1
@@ -405,7 +405,8 @@ }#endif -static inline void context_switch (task_t *prev,task_t *next) +/* This must end up inline or our wchan handling will break, so use extern */ +extern inline void context_switch (task_t *prev,task_t *next) {struct mm_struct *mm = next->mm;struct mm_struct *oldmm = prev->active_mm;
Quoted 8 lines · Anton Blanchard
I noticed on a ppc64 kernel compiled with gcc 3.1 that
context_switchwas left out of line. It ended up outside of the scheduling_functions_start_here/end_here placeholders which breaks wchan.This is one place where we require the code to be inline, so we should use extern.
ABSOLUTELY NOT!
"extern inline" does not guarantee inlining. It only guarantees that _if_ the code isn't inlined, it also won't be compiled as a static function.
Complain to the gcc guys, they've made up some not-backwards-compatible thing called "always_inline" or something, apparently without any way to know whether it is supported or not.
Linus
Quoted 10 lines · Linus Torvalds
Quoted 7 lines · Anton Blanchard
I noticed on a ppc64 kernel compiled with gcc 3.1 that
context_switchwas left out of line. It ended up outside of the scheduling_functions_start_here/end_here placeholders which breaks wchan.This is one place where we require the code to be inline, so we should use extern.
Quoted 8 lines
ABSOLUTELY NOT!
"extern inline" does not guarantee inlining. It only guarantees that _if_ the code isn't inlined, it also won't be compiled as a static function.
Complain to the gcc guys, they've made up some not-backwards-compatible thing called "
always_inline" or something, apparently without any way to know whether it is supported or not.
This is why anything but INLINE or _INLINE (chosen in a Makefile or header) is broken. Every compiler wants something different these days. So, as needed, we get one of:
#define INLINE inline /* sanity! */
#define INLINE extern inline /* an oxymoron */ #define INLINE static inline /* another oxymoron */ #define INLINE __forceinline
#define INLINE __attribute__((always_inline)) #define INLINE inline_me_harder
#define INLINE inline_this_or_I_shove_it_up_your_gnu
BTW, I said this during the "extern inline" to "static inline" conversion.
IMHO "extern inline" and "static inline" are oxymorons and, were it not for the silly C99 standard, ought to produce error messsages. They make as much sense as "extern static" does. The compiler's inability to inline something ought to be an error as well. Oh well.
"Albert D. Cahalan" <[email protected]> writes:
|> The compiler's
|> inability to inline something ought to be an error as well. Oh well.
-Winline -Werror
d&h, Andreas.
Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected] SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 5 lines
ABSOLUTELY NOT!
"extern inline" does not guarantee inlining. It only guarantees that _if_ the code isn't inlined, it also won't be compiled as a static function.
Isnt that the correct behaviour for this function? We rely on that code being inlined so if it doesnt get inlined we should fail to link. Im not solving the problem with this patch, I'll leave that to the gcc guys.
Quoted 3 lines
Complain to the gcc guys, they've made up some not-backwards-compatible thing called "
always_inline" or something, apparently without any way to know whether it is supported or not.
Yes, Alan Modra just pointed me to __attribute__ ((always_inline)).
Anton