From: Paulo Marques <pmarques@grupopie.com>
To: Tomasz Figa <tomasz.figa@gmail.com>
Cc: linux-samsung-soc@vger.kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org, Kukjin Kim <kgene.kim@samsung.com>,
'Ben Dooks' <ben-linux@fluff.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Question about "Inconsistent kallsyms data"
Date: Tue, 02 Aug 2011 17:29:54 +0100 [thread overview]
Message-ID: <4E382602.6050308@grupopie.com> (raw)
In-Reply-To: <1514384.7oMe1aulyC@flatron>
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.
--
Paulo Marques - www.grupopie.com
"All generalizations are false."
WARNING: multiple messages have this Message-ID (diff)
From: pmarques@grupopie.com (Paulo Marques)
To: linux-arm-kernel@lists.infradead.org
Subject: Question about "Inconsistent kallsyms data"
Date: Tue, 02 Aug 2011 17:29:54 +0100 [thread overview]
Message-ID: <4E382602.6050308@grupopie.com> (raw)
In-Reply-To: <1514384.7oMe1aulyC@flatron>
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.
--
Paulo Marques - www.grupopie.com
"All generalizations are false."
WARNING: multiple messages have this Message-ID (diff)
From: Paulo Marques <pmarques@grupopie.com>
To: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
Kukjin Kim <kgene.kim@samsung.com>,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
"'Ben Dooks'" <ben-linux@fluff.org>
Subject: Re: Question about "Inconsistent kallsyms data"
Date: Tue, 02 Aug 2011 17:29:54 +0100 [thread overview]
Message-ID: <4E382602.6050308@grupopie.com> (raw)
In-Reply-To: <1514384.7oMe1aulyC@flatron>
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.
--
Paulo Marques - www.grupopie.com
"All generalizations are false."
next prev parent reply other threads:[~2011-08-02 16:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 1:48 Question about "Inconsistent kallsyms data" Kukjin Kim
2011-07-29 1:48 ` Kukjin Kim
2011-07-29 10:00 ` Tomasz Figa
2011-07-29 10:00 ` Tomasz Figa
2011-07-29 10:02 ` Russell King - ARM Linux
2011-07-29 10:02 ` Russell King - ARM Linux
2011-07-29 10:02 ` Russell King - ARM Linux
2011-07-29 10:58 ` Tomasz Figa
2011-07-29 10:58 ` Tomasz Figa
2011-07-29 11:30 ` Tomasz Figa
2011-07-29 11:30 ` Tomasz Figa
2011-07-29 13:00 ` Arnd Bergmann
2011-07-29 13:00 ` Arnd Bergmann
2011-08-02 16:29 ` Paulo Marques [this message]
2011-08-02 16:29 ` Paulo Marques
2011-08-02 16:29 ` Paulo Marques
2011-10-08 10:17 ` Eric Miao
2011-10-08 10:17 ` Eric Miao
2011-10-08 11:14 ` Arnd Bergmann
2011-10-08 11:14 ` Arnd Bergmann
2011-10-08 11:14 ` Arnd Bergmann
2011-07-29 12:55 ` Arnd Bergmann
2011-07-29 12:55 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E382602.6050308@grupopie.com \
--to=pmarques@grupopie.com \
--cc=ben-linux@fluff.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=tomasz.figa@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.