mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Dooks <ben@fluff.org.uk>
To: Coywolf Qi Hunt <coywolf@gmail.com>
Cc: Ben Dooks <ben@fluff.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mark __init code noinline to stop erroneous inclusions
Date: Tue, 18 Oct 2005 11:38:39 +0100	[thread overview]
Message-ID: <20051018103839.GA32720@home.fluff.org> (raw)
In-Reply-To: <2cd57c900510171803i7b6ccfffwffb378b535f10558@mail.gmail.com>

On Tue, Oct 18, 2005 at 09:03:20AM +0800, Coywolf Qi Hunt wrote:
> On 10/18/05, Ben Dooks <ben@fluff.org.uk> 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@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

      reply	other threads:[~2005-10-18 10:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-17 21:37 Ben Dooks
2005-10-18  1:03 ` Coywolf Qi Hunt
2005-10-18 10:38   ` Ben Dooks [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051018103839.GA32720@home.fluff.org \
    --to=ben@fluff.org.uk \
    --cc=coywolf@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®