From: Sam Ravnborg <sam@ravnborg.org>
To: Michal Marek <mmarek@suse.cz>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
linux-kbuild@vger.kernel.org,
Artem Bityutskiy <dedekind1@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: sections mismatch detection
Date: Fri, 8 Jan 2010 17:27:59 +0100 [thread overview]
Message-ID: <20100108162759.GA16334@merkur.ravnborg.org> (raw)
In-Reply-To: <4B4730C0.6000601@suse.cz>
On Fri, Jan 08, 2010 at 02:18:56PM +0100, Michal Marek wrote:
> Sam Ravnborg napsal(a):
> >> I would prefer to see (logically) the same section mismatch not be
> >> reported multiple times, even though they are in different binary
> >> files. This would reduce the noise level quite a bit IMO.
> >
> > That would be nice but is not trivially doable.
> > We need to discover when there is a section mismatch
> > resulting from for example a function in kernel/*
> > calling a function in arch/$ARCH/kernel so we
> > need to execute the check on multiple levels
> > i order to catch the bugs as early as possible.
> >
> > The easy 'fix' would be to execute the check only
> > on vmlinux.o (default behaviour) but the added
> > checks with the option enabled allows us to
> > be much more precise in reporting where
> > the section mismatch originate from.
>
> But we could remember the (caller,callee) pairs and only emit the first
> warning. Or am I missing something?
The warnings comes from individual calls to mdpost.
When we enable CONFIG_DEBUG_SECTION.. then we will
use modpost to analyse for section mismatches each time we link.
This allows us to emit warnings when we have much better chance
to tell in what .o file we saw the mismatch.
But the downside as Randy also highlight is that the same warning
will be displayed several times as we see it for each linking step.
The nomal way to do section mismatch checks is to only do it
on vmlinux.o and thus we get only one warning per mismatch but
we are much less precise in where it comes from.
Now we could save (caller, callee) from each warning and read
in these and then only emit new warnings.
But it suddenly became non-trivial to do.
And we really want to do the check on several levels.
Think of for example ext4.
Within fs/ext4/ there may be no problems.
But when linkend with the rest of the fs/ subsystem
we may see issues, which is why we need to do the checks on
both level (when we have the config flag enabled).
Sam
next prev parent reply other threads:[~2010-01-08 16:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-06 10:11 Artem Bityutskiy
2010-01-06 10:48 ` Sam Ravnborg
2010-01-06 11:38 ` Michal Marek
2010-01-06 12:04 ` Artem Bityutskiy
2010-01-07 23:03 ` Randy Dunlap
2010-01-08 5:42 ` Sam Ravnborg
2010-01-08 13:18 ` Michal Marek
2010-01-08 16:27 ` Sam Ravnborg [this message]
2010-01-08 16:32 ` Michal Marek
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=20100108162759.GA16334@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=dedekind1@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=rdunlap@xenotime.net \
/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®