Question about "Inconsistent kallsyms data"
eric.y.miao at gmail.com
Sat Oct 8 06:17:49 EDT 2011
On Wed, Aug 3, 2011 at 12:29 AM, Paulo Marques <pmarques at grupopie.com> wrote:
> Tomasz Figa wrote:
>> On Friday 29 of July 2011 at 12:58:32, Tomasz Figa wrote:
>>> I will try to bisect the case with s3c6400 defconfig.
>> I have no idea why, but I cannot reproduce the issue anymore, even after make
>> distclean or starting with a clean tree. A build system bug?
>> I do not know much technical details about the kernel build system, but might
>> it be a concurrency issue (I use make -j5 for building with 5 jobs)?
> Usually this is caused by symbols moving slightly between kernel compiles.
> This is an explanation of the process I wrote a while ago in a different
> thread at LKML:
>> Now as for CONFIG_KALLSYMS_EXTRA_PASS: to build the kallsyms table, the
>> build process first links a kernel image with an empty kallsyms table
>> and use that to fetch information for all the symbols.
>> It then uses that information to build the table with the right size,
>> and links it again. If everything goes ok, this new version as all the
>> symbols in the correct places and the final table can be built with the
>> correct addresses.
>> The final linking should produce the same result as only the data on the
>> kallsyms table changed, but not its size.
>> However, there have been bugs in the past with section alignments and
>> symbol reordering for symbols with the same address, etc., etc. that
>> make this final table not have the exact same size, and the build fails
>> with an inconsistent kallsyms data message. At this point, the user can
>> turn on the CONFIG_KALLSYMS_EXTRA_PASS and temporarily solve the problem
>> while the developers find the correct fix. Without this option, in this
>> situation the kernel would simply fail the compilation.
>> All this has been stable for a while and this option hasn't been needed
>> recently (AFAIK), but if there is some bug in some new binutils or
>> something, the option might be needed again.
> To check inconsistencies, the Makefile compares ".tmp_System.map" and
> "System.map" for differences.
> On a normal build they should be identical, but if this fails with
> "Inconsistent kallsyms data" you could try comparing the two files to
> check which symbols are causing trouble.
I met this issue today as well. Didn't have a chance to compare the
files, as I did a 'rm -fr ../build' and reconfigured/re-built everything,
and 'make O=../build clean' didn't work for me.
I'm using a toolchain with version info as below:
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3)
> Paulo Marques - www.grupopie.com
> "All generalizations are false."
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
More information about the linux-arm-kernel