All of lore.kernel.org
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Link failures due to __bug_table in current -next
Date: Tue, 20 Sep 2011 19:51:21 +0100	[thread overview]
Message-ID: <20110920185121.GA17169@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAPnjgZ2-Ttmoa8zwSVqL70vXDoJv=-Z2XyVBuTi-bm4-0c6E-Q@mail.gmail.com>

On Tue, Sep 20, 2011 at 10:00:06AM -0700, Simon Glass wrote:
> On Tue, Sep 20, 2011 at 12:59 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > It's not that simple though - if you read the quote from the linker manual,
> > the implication is that the linker would be entirely free to discard an
> > input section as a priority if it appears in a discard section anywhere
> > in the linker script. ?There's nothing to say future linkers won't do
> > this. ?It would still be conformant to the linker manual.
> 
> Oh dear. That is why it might be a good idea to hassle the linker
> people, since relying on experiments on how things currently work
> might be risky if someone leaps in and changes the algorithm.

Or we just ensure that we conform to the apparant looseness of the
manual, and make the addition of EXIT_TEXT etc in DISCARDS conditional
(which is effectively what I'm doing with my patch.)

That means we're no longer reliant on trusting the linker to do what
we want for this (we _do_ still trust it for the unwind information,
but I think that's less of an issue.)

> Hmm even more out there, I wonder if we can modify the BUG macro to
> put the bug table entry into one of two separate depending on whether
> BUG is in an __exit function or not? Then at link time, either concat
> the two tables, or just ignore the exit one...

That was the same thought for the SMP alternatives problem - I think
Nicolas proposed that there should be some way that the linker can
do sections based on the current section name.  That'd allow us to
have .alt.smp.exit.text and __bug_table.exit.text etc.

> In any case, it sounds from the next email in this thread that your
> patch has fixed the problem! So, where does that leave us?

I think we apply the patch, which resolves the problem, and point it
out to whoever looks after the asm-generic/vmlinux.lds.S file (Arnd?
I'll check when I re-dock the laptop later this evening.)  I suspect
Arnd is already reading some of these messages...

  reply	other threads:[~2011-09-20 18:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-19 12:09 Link failures due to __bug_table in current -next Mark Brown
2011-09-19 18:40 ` Russell King - ARM Linux
2011-09-19 18:42   ` Mark Brown
2011-09-19 18:58     ` Russell King - ARM Linux
2011-09-19 19:06       ` Mark Brown
2011-09-19 19:16         ` Russell King - ARM Linux
2011-09-20  7:35           ` Uwe Kleine-König
2011-09-19 19:12       ` Russell King - ARM Linux
2011-09-19 20:03 ` Russell King - ARM Linux
2011-09-20  7:06   ` Simon Glass
2011-09-20  7:59     ` Russell King - ARM Linux
2011-09-20 17:00       ` Simon Glass
2011-09-20 18:51         ` Russell King - ARM Linux [this message]
2011-09-20 19:13           ` Arnd Bergmann
2011-09-20 19:57           ` Nicolas Pitre
2011-09-21 22:58             ` Simon Glass
2011-09-21 22:45           ` Simon Glass
2011-09-20 11:02   ` Mark Brown

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=20110920185121.GA17169@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.