From: David Miller <davem@davemloft.net>
To: roland@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: "build-id" changes break sparc64
Date: Sun, 22 Jul 2007 01:23:21 -0700 (PDT) [thread overview]
Message-ID: <20070722.012321.79430375.davem@davemloft.net> (raw)
(This is in reference to commit 18991197b4b588255ccabf472ebc84db7b66a19c)
When actually used, the build-id linker option causes problems for the
sparc64 kernel in two ways:
1) When building modules we get tons of warnings from the linker
such as:
LD [M] drivers/scsi/sr_mod.o
ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
2) The resulting kernel image will not boot. The SILO boot loader on
sparc aborts if there are multiple PT_LOAD segments in the ELF
program header of the kernel image. The boot loader can only
handle allocating memory for and setting up mappings via the
firmware for one one linear PT_LOAD segment.
build-id puts a second PT_LOAD into the kernel image (albeit a tiny
one) and as a result it cannot be booted
This is all with the current binutils in Ubuntu gutsy which
is version 2.17.50.20070718
Whilst #1 could be some kind of binutils bug and the warning
is harmless, #2 is an outright show-stopper for sparc32 and
sparc64 and to be honest I would not be surprised if the
boot loader on some other platforms have this limitation too.
My suggestion would be to add this linker option in the various
arch/${FOO}/Makefile files for platforms and situations where it
is known to work properly.
Roland, if you agree could you submit a fix like that?
Alternatively, if you think build-id is so valuable, impress me with
your binutils ninja skills and show me how to perhaps do some objcopy
tricks wherein I could dike out the PT_LOAD segment build-id generates
for the "image" target et al. in the arch/sparc{,64}/boot/Makefile's
rules.
Thanks a lot.
next reply other threads:[~2007-07-22 8:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-22 8:23 David Miller [this message]
2007-07-22 8:59 ` Roland McGrath
2007-07-23 2:18 ` David Miller
2007-07-23 6:01 ` Roland McGrath
2007-07-23 6:13 ` Paul Mackerras
2007-07-23 6:27 ` Sam Ravnborg
2007-07-23 7:26 ` Roland McGrath
2007-07-23 8:14 ` Sam Ravnborg
2007-07-23 8:18 ` Roland McGrath
2007-07-23 8:24 ` Sam Ravnborg
2007-07-23 9:25 ` Alan Modra
2007-07-23 11:49 ` Al Viro
2007-07-23 18:00 ` Sam Ravnborg
2007-07-23 18:56 ` Al Viro
2007-07-23 19:13 ` Adrian Bunk
2007-07-23 19:12 ` Roland McGrath
2007-07-23 19:39 ` Al Viro
2007-07-23 20:05 ` Roland McGrath
2007-07-23 20:33 ` Sam Ravnborg
2007-07-23 6:14 ` [PATCH] Move --build-id option Roland McGrath
2007-07-23 6:42 ` Sam Ravnborg
2007-07-23 8:09 ` Roland McGrath
2007-07-23 8:12 ` [PATCH] Use LDFLAGS_MODULE only for .ko links Roland McGrath
2007-07-23 8:16 ` Sam Ravnborg
2007-07-23 6:22 ` "build-id" changes break sparc64 Sam Ravnborg
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=20070722.012321.79430375.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome