From: Jon Masters <jonathan@jonmasters.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Arnd Bergmann <arnd@arndb.de>,
linux-kbuild@vger.kernel.org
Subject: Re: Inconsistent kallsyms data on ARM.
Date: Mon, 26 Mar 2012 09:07:44 -0400 [thread overview]
Message-ID: <4F706A20.6020302@jonmasters.org> (raw)
In-Reply-To: <20120326073704.GH5611@n2100.arm.linux.org.uk>
On 03/26/2012 03:37 AM, Russell King - ARM Linux wrote:
> On Sun, Mar 25, 2012 at 07:59:44PM -0400, Jon Masters wrote:
>> As to longer term, I am happy to work up something that will spot this
>> particular kind of failure (symbol changes type) and output something
>> more useful during the kallsyms generation if you would like.
>>
>> Are you planning to pull in either of the fixes you mention?
>
> I'm not, because those are all sub-optimal - I don't see why we should
> bloat the kernel image just for the sake of working around kallsyms.
>
> The best I've come up with so far which avoids that is to force
> KALLSYMS_EXTRA_PASS to always be set on ARM.
Or just increasing the base number of kallsyms runs on ARM? That way,
you can have a real extra extra pass in the case of something else :)
Jon.
WARNING: multiple messages have this Message-ID (diff)
From: jonathan@jonmasters.org (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: Inconsistent kallsyms data on ARM.
Date: Mon, 26 Mar 2012 09:07:44 -0400 [thread overview]
Message-ID: <4F706A20.6020302@jonmasters.org> (raw)
In-Reply-To: <20120326073704.GH5611@n2100.arm.linux.org.uk>
On 03/26/2012 03:37 AM, Russell King - ARM Linux wrote:
> On Sun, Mar 25, 2012 at 07:59:44PM -0400, Jon Masters wrote:
>> As to longer term, I am happy to work up something that will spot this
>> particular kind of failure (symbol changes type) and output something
>> more useful during the kallsyms generation if you would like.
>>
>> Are you planning to pull in either of the fixes you mention?
>
> I'm not, because those are all sub-optimal - I don't see why we should
> bloat the kernel image just for the sake of working around kallsyms.
>
> The best I've come up with so far which avoids that is to force
> KALLSYMS_EXTRA_PASS to always be set on ARM.
Or just increasing the base number of kallsyms runs on ARM? That way,
you can have a real extra extra pass in the case of something else :)
Jon.
next prev parent reply other threads:[~2012-03-26 13:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 22:00 Inconsistent kallsyms data on ARM Paul Gortmaker
2012-03-13 22:00 ` Paul Gortmaker
2012-03-14 13:21 ` Arnd Bergmann
2012-03-14 13:21 ` Arnd Bergmann
2012-03-25 11:20 ` Russell King - ARM Linux
2012-03-25 11:20 ` Russell King - ARM Linux
2012-03-25 23:59 ` Jon Masters
2012-03-25 23:59 ` Jon Masters
2012-03-25 23:59 ` Jon Masters
2012-03-26 7:37 ` Russell King - ARM Linux
2012-03-26 7:37 ` Russell King - ARM Linux
2012-03-26 7:45 ` Uwe Kleine-König
2012-03-26 7:45 ` Uwe Kleine-König
2012-03-26 7:45 ` Uwe Kleine-König
2012-03-26 8:39 ` Arnd Bergmann
2012-03-26 8:39 ` Arnd Bergmann
2012-03-26 8:39 ` Arnd Bergmann
2012-03-26 13:07 ` Jon Masters [this message]
2012-03-26 13:07 ` Jon Masters
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=4F706A20.6020302@jonmasters.org \
--to=jonathan@jonmasters.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul.gortmaker@windriver.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.