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 <rmk+lkml@xxxxxxxxxxxxxxxx> 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 <catalin.marinas@xxxxxxx> wrote: > > > > > > > > Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
