On Fri, Mar 28, 2014 at 10:54:13AM +0000, David Laight wrote:

From: Hannes Frederic Sowa

quoted

quoted

quoted

Perhaps all the __inline__ uses could be changed to inline too.

Or rather, deleted completely, this is a *.c file after all.

Personally I wouldn't do a blanket removal of 'inline' from .c files.
But I will agree that some large functions have been inappropriately
marked 'inline'.

Does inline keyword actually make a difference in case the function is
static? I guess not (except for function profiling if a prologue should
get included, thus the change in visibility for tracing).

The complier doesn't always make the right guess.

quoted

Smart-arsing:

Removing inline keyword makes the function visible to tracing if
it didn't get inlined. I think this is a nice side-effect because debug
kernels are often compiled with less aggressive inlining options
(readable asm kconfig option).

I want to debug the same binary that will run in production.
Dodgy code can be affected by all sorts of compiler options.

I agree. But status quo is that your binaries look very different if
you have DEBUG_SECTION_MISMATCH or READABLE_ASM defined.

The change in tracing visibility is already the case if you (like
me) compile your kernel with DEBUG_SECTION_MISMATCH wich enables
no-inline-functions-called-once, because this option does also not
respect inline keyword.

The best one was a problem with the shell deleting the last
character of a $(...) substitution.
The code ran off the beginning of an on-stack buffer when trimming
trailing '\n' and 'found' a '\n' byte lurking in the unwritten
stack (this was well down the stack, and had been written much,
much earlier).
The error was only ever likely on big-endian systems (the msb of
a word is less likely to be '\n'.

Heh. :)

Greetings,

  Hannes