All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Jon Masters <jonathan@jonmasters.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org
Subject: Re: Inconsistent kallsyms data on ARM.
Date: Mon, 26 Mar 2012 08:39:46 +0000	[thread overview]
Message-ID: <201203260839.46858.arnd@arndb.de> (raw)
In-Reply-To: <20120326074533.GL15647@pengutronix.de>

On Monday 26 March 2012, Uwe Kleine-König wrote:
> On Mon, Mar 26, 2012 at 08:37:04AM +0100, 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.
> Just to let you know: I even saw failures with KALLSYMS_EXTRA_PASS set.
> Not so in the recent past and sometimes not even reproducible IIRC.
> I will save the build results next time it happens now that I saw what
> to look for.

Yes, I saw these too in my randconfig builds some time ago. Maybe a handful
of builds among 50000 configurations.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Jon Masters <jonathan@jonmasters.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org
Subject: Re: Inconsistent kallsyms data on ARM.
Date: Mon, 26 Mar 2012 08:39:46 +0000	[thread overview]
Message-ID: <201203260839.46858.arnd@arndb.de> (raw)
In-Reply-To: <20120326074533.GL15647@pengutronix.de>

On Monday 26 March 2012, Uwe Kleine-König wrote:
> On Mon, Mar 26, 2012 at 08:37:04AM +0100, 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.
> Just to let you know: I even saw failures with KALLSYMS_EXTRA_PASS set.
> Not so in the recent past and sometimes not even reproducible IIRC.
> I will save the build results next time it happens now that I saw what
> to look for.

Yes, I saw these too in my randconfig builds some time ago. Maybe a handful
of builds among 50000 configurations.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Inconsistent kallsyms data on ARM.
Date: Mon, 26 Mar 2012 08:39:46 +0000	[thread overview]
Message-ID: <201203260839.46858.arnd@arndb.de> (raw)
In-Reply-To: <20120326074533.GL15647@pengutronix.de>

On Monday 26 March 2012, Uwe Kleine-K?nig wrote:
> On Mon, Mar 26, 2012 at 08:37:04AM +0100, 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.
> Just to let you know: I even saw failures with KALLSYMS_EXTRA_PASS set.
> Not so in the recent past and sometimes not even reproducible IIRC.
> I will save the build results next time it happens now that I saw what
> to look for.

Yes, I saw these too in my randconfig builds some time ago. Maybe a handful
of builds among 50000 configurations.

	Arnd

  reply	other threads:[~2012-03-26  8:39 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 [this message]
2012-03-26  8:39             ` Arnd Bergmann
2012-03-26  8:39             ` Arnd Bergmann
2012-03-26 13:07         ` Jon Masters
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=201203260839.46858.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=jonathan@jonmasters.org \
    --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 \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.