[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100108162759.GA16334@merkur.ravnborg.org>
Date: Fri, 8 Jan 2010 17:27:59 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: Michal Marek <mmarek@...e.cz>
Cc: Randy Dunlap <rdunlap@...otime.net>, linux-kbuild@...r.kernel.org,
Artem Bityutskiy <dedekind1@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: sections mismatch detection
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists