Re: (hacky) [PATCH] silence MODPOST section mismatch warnings

[Sam Ravnborg]

On Thu, May 10, 2007 at 10:59:20PM +0100, Russell King wrote:
> On Thu, May 10, 2007 at 02:07:25PM -0700, David Miller wrote:
> > From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
> > Date: Thu, 10 May 2007 21:54:27 +0100
> > 
> > > I've not had one accurate one on ARM yet.
> > > 
> > > Here's another example:
> > > 
> > > WARNING: init/built-in.o - Section mismatch: reference to .init.text:
> > >  from .text between 'rest_init' (at offset 0x4c) and 'run_init_process'
> > > 
> > > from init/main.c:
> > > 
> > > static void noinline rest_init(void)
> > >         __releases(kernel_lock)
> > > 
> > > static void run_init_process(char *init_filename)
> > > 
> > > Clearly, it just does _not_ work.
> > 
> > Russell, the symbols are where the reference to an .init.text
> > section are coming from, they are not the .init.text function
> > being referenced itself.
> > 
> > It is saying that something between rest_init and run_init_processes,
> > which are not .init.text, are referencing an .init.text object.
> 
> I'd like to make a suggestion to make the wording of the warning
> clearer:
> 
> WARNING: init/built-in.o(.text+0x4c): section mismatch: reference to
>  .init.text:blah (between 'rest_init' and 'run_init_process')
> 
> I think this would remove the confusion - the primary information
> relating to where the reference is located is contained together
> ("init/built-in.o(.text+0x4c)") and the confusing "between" clause
> which seems to only be a hint becomes entirely secondary.
> 
> Moreover, it's similar to binutils warnings - which are of the form:
> 
> file:(section+offset): message

I like the new format - thanks!
Did you drop the ':' after the file on purpose?

[I am not familiar with this particular binutils warning so I did not
know an easy way to provoke it]

PS. Will apply the path you submitted in next mail.

	Sam
-
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/