From: Ben Dooks <ben-linux@fluff.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Al Viro <viro@ftp.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Keith Ownes <kaos@ocs.com.au>
Subject: Re: kbuild - status on section mismatch warnings
Date: Sun, 5 Mar 2006 22:04:01 +0000 [thread overview]
Message-ID: <20060305220401.GA25816@home.fluff.org> (raw)
In-Reply-To: <20060305215853.GA14998@mars.ravnborg.org>
On Sun, Mar 05, 2006 at 10:58:53PM +0100, Sam Ravnborg wrote:
> Hi Al.
>
> > Now try x86 with sd.o non-modular. And see
> >
> >
> > __init foo()
> > {
> > ....
> > switch(n) {
> > ....
> > ....
> > }
> > }
> Hmm, in my tree sd.o has no switch in the init function. But that does
> not change your point which is valid indeed.
>
> > compiling essentially into
> >
> > if (n < lower || n > upper)
> > goto Ldefault;
> > addr = const_array_of_labels[n - lower];
> > goto addr;
> >
> > with const_array_of_labels sitting in .rodata and its contents pointing
> > inside foo(), i.e. into .init.text. And yes, .init.text is discarded,
> > while .rodata is left intact. Since the only reference to that array
> > disappears along with .init.text *and* section where array goes into is
> > hardwired into gcc, we
> > a) are actually OK and
> > b) can't do anything about that false positive, AFAICS.
>
> For the same reason references to .init.text from .rodata are not warned
> upon - there are simply too many compielr generated false positives.
>
> Following is the original comment from reference_init.pl:
>
> * Unfortunately references to read only data that referenced .init
> * sections had to be excluded. Almost all of these are false
> * positives, they are created by gcc. The downside of excluding rodata
> * is that there really are some user references from rodata to
> * init code, e.g. drivers/video/vgacon.c:
> *
> * const struct consw vga_con = {
> * con_startup: vgacon_startup,
> *
> * where vgacon_startup is __init. If you want to wade through
> * the false
> * positives, take out the check for rodata.
>
> And this is unfortunate since we cannot do a full check, but we do a
> better job than before and warn for many of the trivial cases.
> Judging the amount of warnings already generated this is worth checking.
I think the best way to be with an extension to sparse to
check calls from non-init marked code do not to go to items
marked init unless forced to.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
next prev parent reply other threads:[~2006-03-05 22:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-05 19:30 kbuild - status on section mismatch warnings Sam Ravnborg
2006-03-05 20:06 ` Al Viro
2006-03-05 21:58 ` Sam Ravnborg
2006-03-05 22:04 ` Ben Dooks [this message]
2006-03-05 22:39 ` Sam Ravnborg
2006-03-05 23:52 ` Al Viro
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=20060305220401.GA25816@home.fluff.org \
--to=ben-linux@fluff.org \
--cc=akpm@osdl.org \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=viro@ftp.linux.org.uk \
/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