On Wed, May 16, 2007 at 01:59:53PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> On Tue, 15 May 2007 22:39:35 +0200 Sam Ravnborg <[email protected]> wrote:
> > On Fri, May 11, 2007 at 03:45:01PM +1000, Stephen Rothwell wrote:
> > > which we want to skip during modpost processing. We need this to make
> > > some of the whitelisting work.
> > I have a popwerpc64 crosscompiler and would like to reproduce
> > this bug.
> > What config shall I use to try it out.
> I use allmodconfig, but that doesn't really build at the moment, so I
> have attached a config that should build (with a recent Linus tree).
> > Can you please supply the exact warning message too.
> WARNING: mm/built-in.o - Section mismatch: reference to .init.text:.__alloc_bootmem_node from .text between '.sparse_index_alloc' (at offset 0x27df0) and '.__section_nr'
> The '.sparse_index_alloc' doesn't match "sparse_index_alloc" in pat4sym
> due to the '.' at the beginning. I have seen another one as well, but
> cannot reproduce it at the moment.
I'm reluctant to apply this patch for two reasons.
1) I cannot reproduce it
2) The cases that this patch would repair are most likely
better addressed by the upcoming __init_refok marker.
ad 1) I think the alloc_bootmem warning was fixed by
correcting the __init / __initdata markes so it got
fixed in the rigt way and not by whitelisting.
I had a bunch or warnings like this:
WARNING: arch/ppc/platforms/built-in.o(.data+0x18): Section mismatch: reference to .init.text:Powerplus_Map_Non0 (between 'mot_info' and 'Mesquite_pci_IRQ_map')
This is mot_info that should be marked __initdata - shall I post a patch?
And one warning like this:
WARNING: arch/ppc/mm/built-in.o(.text+0x1000): Section mismatch: reference to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'hash_page_sync')
The latter is a __init_Refok candidate.
The logic make sure we call early_get_page only if we are in init mode.
I also saw a number of:
WARNING: "next_slot" [arch/ppc/mm/built-in] is COMMON symbol
I can see where modpost post this warning but I do not know the rationale
The symbols that modpost complain about are all assembler defined symbols.
Maybe something needs to be fixed in the assembler code?
The offending symbols are marked with .comm but other global symbols
are marked with _GLOBAL(symbol).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]