On Wed, Aug 3, 2011 at 12:29 AM, Paulo Marques <pmarques@xxxxxxxxxxxx> 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. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --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 --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib 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@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |