Re: [PATCH] mark __init code noinline to stop erroneous inclusions

[Ben Dooks]

On Tue, Oct 18, 2005 at 09:03:20AM +0800, Coywolf Qi Hunt wrote:
> On 10/18/05, Ben Dooks <ben@xxxxxxxxxxxx> wrote:
> > Make __init also have the noinline attribute attached
> > to it, to stop code marked as __init being included
> > into non __init code. This not only wastes space, but
> > also makes it impossible to track down any calls from
> > non-init code as differing compilers and optimisations
> > make differing decisions on what to inline.
> 
> I think this is overkill. __init code could be inlined into __init
> code.  Instead we should make sure to not to call __init code from
> non-init code `directly'.

This is very difficult to detect when the compiler is inlining the
function code. 
 
> It is a gcc bug. Gcc really should respects __attribute__
> ((__section__ (".init.text"))), and not inline the code in that
> section.


>From the gcc 4.0 manual,
http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html

section ("section-name")
    Normally, the compiler places the code it generates in the
    text section. Sometimes, however, you need additional sections,
    or you need certain particular functions to appear in special sections.
    The section attribute specifies that a function lives in a particular
    section.

My reading of the passage is that the output code will be put in
the specified section. It does not say wether or not the compiler
is allowed to do any other optimisations it sees fit on the data.

My belief is that the compiler should be able to do this form of
optimisation, unless we tell it otherwise. The only harm is that
it makes it difficult to detect errors from compilers that do not
do it.

-- 
Ben (ben@xxxxxxxxx, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/