Hi Russell,
Over the past few days, I have started getting some arm configs (at least
iop13xx_defconfig and integrator_defconfig, but some others) failing to
build getting this error:
SYSMAP System.map
SYSMAP .tmp_System.map
Inconsistent kallsyms data
Try setting CONFIG_KALLSYMS_EXTRA_PASS
Is this something you have seen? Could it be my toolchain (I am
currently using gcc 4.4.0 and have not changed it recently)?
I first saw this with next-20090615 i.e. Monday's tree. Some configs
seem to have recovered, but others only hit it yesterday and some have
not hit it at all. See http://kisskb.ellerman.id.au/kisskb/branch/9/
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen Rothwell <[email protected]> wrote:
> Over the past few days, I have started getting some arm configs (at least
> iop13xx_defconfig and integrator_defconfig, but some others) failing to
> build getting this error:
>
> SYSMAP System.map
> SYSMAP .tmp_System.map
> Inconsistent kallsyms data
> Try setting CONFIG_KALLSYMS_EXTRA_PASS
>
> Is this something you have seen? Could it be my toolchain (I am
> currently using gcc 4.4.0 and have not changed it recently)?
I reported an error with kallsysms on ARM this Monday leading to
inconsistent data:
http://lkml.org/lkml/2009/6/15/233
Could it be related?
--
Catalin
Hi Catalin,
On Wed, 17 Jun 2009 09:34:31 +0100 Catalin Marinas <[email protected]> wrote:
>
> Stephen Rothwell <[email protected]> wrote:
> > Over the past few days, I have started getting some arm configs (at least
> > iop13xx_defconfig and integrator_defconfig, but some others) failing to
> > build getting this error:
> >
> > SYSMAP System.map
> > SYSMAP .tmp_System.map
> > Inconsistent kallsyms data
> > Try setting CONFIG_KALLSYMS_EXTRA_PASS
> >
> > Is this something you have seen? Could it be my toolchain (I am
> > currently using gcc 4.4.0 and have not changed it recently)?
>
> I reported an error with kallsysms on ARM this Monday leading to
> inconsistent data:
>
> http://lkml.org/lkml/2009/6/15/233
>
> Could it be related?
Could be. I have added the proposed fix patch to my fixes tree until
Linus or Sam gets around to including it.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Wed, Jun 17, 2009 at 11:08:04PM +1000, Stephen Rothwell wrote:
> Hi Catalin,
>
> On Wed, 17 Jun 2009 09:34:31 +0100 Catalin Marinas <[email protected]> wrote:
> >
> > Stephen Rothwell <[email protected]> wrote:
> > > Over the past few days, I have started getting some arm configs (at least
> > > iop13xx_defconfig and integrator_defconfig, but some others) failing to
> > > build getting this error:
> > >
> > > SYSMAP System.map
> > > SYSMAP .tmp_System.map
> > > Inconsistent kallsyms data
> > > Try setting CONFIG_KALLSYMS_EXTRA_PASS
> > >
> > > Is this something you have seen? Could it be my toolchain (I am
> > > currently using gcc 4.4.0 and have not changed it recently)?
> >
> > I reported an error with kallsysms on ARM this Monday leading to
> > inconsistent data:
> >
> > http://lkml.org/lkml/2009/6/15/233
> >
> > Could it be related?
>
> Could be. I have added the proposed fix patch to my fixes tree until
> Linus or Sam gets around to including it.
No, I don't think it's got anything to do with it. It's the kallsyms
generator that's getting confused.
What's happening is that we're ending up with differences between the
symbolic information generated for .tmp_vmlinux2 and vmlinux:
c024c638 t svc_pool_stats_seq_ops
c024c648 t rpc_proc_fops
c024c6b0 T kallsyms_addresses
-c024ea10 T kallsyms_num_syms
-c024ea20 T kallsyms_names
-c0253990 T kallsyms_markers
-c02539c0 T kallsyms_token_table
-c0253d70 T kallsyms_token_index
+c024ea00 T kallsyms_num_syms
+c024ea10 T kallsyms_names
+c0253970 T kallsyms_markers
+c02539a0 T kallsyms_token_table
+c0253d50 T kallsyms_token_index
c027b000 r __pci_fixup_PCI_VENDOR_ID_VIA0x324equirk_via_cx700_pci_parking_caching
c027b000 R __start_pci_fixups_early
c027b000 R __start_rodata
>From what I can tell, what happens is the following:
- link kernel into .tmp_vmlinux1 - thereby containing only weak references
to the kallsyms data
- generate .tmp_kallsyms1.S and assemble it
- link kernel plus .tmp_kallsyms1.o into .tmp_vmlinux2. This now contains
kallsyms data, but based upon the kernel without any such data. The
symbolic addresses are therefore all wrong.
- generate .tmp_kallsyms2.S and assemble it
- link kernel plus .tmp_kallsyms2.o into vmlinux. This contains the kallsyms
data, but in theory the only difference is that the addresses should now
be correct.
Now, what seems to be happening in this case is that for .tmp_vmlinux1,
_etext != _data - in other words, the ". = ALIGN(THREAD_SIZE);" statement
is having to do something:
c02880c4 R __stop___param
c0289000 R __end_rodata
c0289000 A _etext
c028a000 A __data_loc
c028a000 D _data
c028a000 D _sdata
c028a000 D init_thread_union
However, for .tmp_vmlinux2, _etext == _data:
c028f0c4 R __stop___param
c0290000 A __data_loc
c0290000 R __end_rodata
c0290000 D _data
c0290000 A _etext
c0290000 D _sdata
c0290000 D init_thread_union
I think the significance of this is the sorting algorithm in kallsyms.c,
and therefore the way the symbolic information gets compressed. This
causes the tables produced in .tmp_kallsyms1.S and .tmp_kallsyms2.S to
be rather different - particularly size-wise - we can see that
kallsyms_addresses has shrunk by 16 bytes. (Note that kallsyms_num_syms
is aligned to 8 bytes, so it could be 12 bytes... see the next data point
below.)
It also appears that 3 symbols disappeared between .tmp_kallsyms1.S and
.tmp_kallsyms2.S - get the diff of 'arm-linux-nm -n' output between
.tmp_vmlinux1 and .tmp_vmlinux2 shows no fewer symbols. If that
translates to 3 fewer addresses in the kallsyms_addresses table,
that'd explain why its shrunk.
The question is... what are these three magically disappearing symbols
and why have they disappeared? Are they related to the reshuffling
of _etext and __end_rodata vs _data?
I've tried seeing if there's a change to our vmlinux.lds.S file that's
caused this, but my only solution which so far has worked is to add a
". += 4;" after "_etext = .;" to force separation of _data from _etext.
I'm not sure wasting 8K in this way is going to please many people
though, so I wouldn't call it a solution.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hi Russell,
On Fri, 19 Jun 2009 16:13:21 +0100 Russell King <[email protected]> wrote:
>
> On Wed, Jun 17, 2009 at 11:08:04PM +1000, Stephen Rothwell wrote:
> >
> > On Wed, 17 Jun 2009 09:34:31 +0100 Catalin Marinas <[email protected]> wrote:
> > >
> > > Stephen Rothwell <[email protected]> wrote:
> > > > Over the past few days, I have started getting some arm configs (at least
> > > > iop13xx_defconfig and integrator_defconfig, but some others) failing to
> > > > build getting this error:
> > > >
> > > > SYSMAP System.map
> > > > SYSMAP .tmp_System.map
> > > > Inconsistent kallsyms data
> > > > Try setting CONFIG_KALLSYMS_EXTRA_PASS
> > > >
> > > > Is this something you have seen? Could it be my toolchain (I am
> > > > currently using gcc 4.4.0 and have not changed it recently)?
> > >
> > > I reported an error with kallsysms on ARM this Monday leading to
> > > inconsistent data:
> > >
> > > http://lkml.org/lkml/2009/6/15/233
> > >
> > > Could it be related?
> >
> > Could be. I have added the proposed fix patch to my fixes tree until
> > Linus or Sam gets around to including it.
>
> No, I don't think it's got anything to do with it. It's the kallsyms
> generator that's getting confused.
>
> What's happening is that we're ending up with differences between the
> symbolic information generated for .tmp_vmlinux2 and vmlinux:
I do wonder if the above could be the root cause, though. Since I added
the added the fix mentioned above to linux-next, my arm builds have not
failed do to this problem. Or maybe this "fix" just works around another
problem?
In any case, it would be nice if the fix (repeated below) could be sent
to Linus by someone (it also fixes a problem that Dave Miller is seeing).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
From: Mike Frysinger <[email protected]>
Date: Mon, 15 Jun 2009 07:52:48 -0400
Subject: [PATCH] kallsyms: fix inverted valid symbol checking
The previous commit (17b1f0de) introduced a slightly broken consolidation
of the memory text range checking.
Signed-off-by: Mike Frysinger <[email protected]>
---
scripts/kallsyms.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 3cb5789..64343cc 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -167,11 +167,11 @@ static int symbol_valid_tr(struct sym_entry *s)
for (i = 0; i < ARRAY_SIZE(text_ranges); ++i) {
tr = &text_ranges[i];
- if (s->addr >= tr->start && s->addr < tr->end)
- return 0;
+ if (s->addr >= tr->start && s->addr <= tr->end)
+ return 1;
}
- return 1;
+ return 0;
}
static int symbol_valid(struct sym_entry *s)
--
1.6.3.1
On Sat, Jun 20, 2009 at 03:54:40PM +1000, Stephen Rothwell wrote:
> Hi Russell,
>
> On Fri, 19 Jun 2009 16:13:21 +0100 Russell King <[email protected]> wrote:
> >
> > On Wed, Jun 17, 2009 at 11:08:04PM +1000, Stephen Rothwell wrote:
> > >
> > > On Wed, 17 Jun 2009 09:34:31 +0100 Catalin Marinas <[email protected]> wrote:
> > > >
> > > > Stephen Rothwell <[email protected]> wrote:
> > > > > Over the past few days, I have started getting some arm configs (at least
> > > > > iop13xx_defconfig and integrator_defconfig, but some others) failing to
> > > > > build getting this error:
> > > > >
> > > > > SYSMAP System.map
> > > > > SYSMAP .tmp_System.map
> > > > > Inconsistent kallsyms data
> > > > > Try setting CONFIG_KALLSYMS_EXTRA_PASS
> > > > >
> > > > > Is this something you have seen? Could it be my toolchain (I am
> > > > > currently using gcc 4.4.0 and have not changed it recently)?
> > > >
> > > > I reported an error with kallsysms on ARM this Monday leading to
> > > > inconsistent data:
> > > >
> > > > http://lkml.org/lkml/2009/6/15/233
> > > >
> > > > Could it be related?
> > >
> > > Could be. I have added the proposed fix patch to my fixes tree until
> > > Linus or Sam gets around to including it.
> >
> > No, I don't think it's got anything to do with it. It's the kallsyms
> > generator that's getting confused.
> >
> > What's happening is that we're ending up with differences between the
> > symbolic information generated for .tmp_vmlinux2 and vmlinux:
>
> I do wonder if the above could be the root cause, though. Since I added
> the added the fix mentioned above to linux-next, my arm builds have not
> failed do to this problem. Or maybe this "fix" just works around another
> problem?
>
> In any case, it would be nice if the fix (repeated below) could be sent
> to Linus by someone (it also fixes a problem that Dave Miller is seeing).
Just sent it. Overloaded with day-time stuff (again).
Sam
On Sat, Jun 20, 2009 at 02:41:52PM +0200, Sam Ravnborg wrote:
> Just sent it. Overloaded with day-time stuff (again).
Sam, thanks, it does appear to solve the problem here as well.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hi Sam,
On Sat, 20 Jun 2009 14:41:52 +0200 Sam Ravnborg <[email protected]> wrote:
>
> Just sent it. Overloaded with day-time stuff (again).
Thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/