From: Jakub Jelinek <jakub@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: binutils@sources.redhat.com
Subject: [PATCH] Issues with ld -shared --build-id
Date: Tue, 24 Jul 2007 20:56:00 -0000 [thread overview]
Message-ID: <20070724202224.GH4603@sunsite.mff.cuni.cz> (raw)
Hi!
ld -shared --build-id creates bad DSOs:
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.gnu.build-i NOTE 00000000 001000 000024 00 A 0 0 4
[ 2] .gnu.hash GNU_HASH 000000d4 0010d4 000040 04 A 3 0 4
[ 3] .dynsym DYNSYM 00000114 001114 0000b0 10 A 4 1 4
[ 4] .dynstr STRTAB 000001c4 0011c4 000071 00 A 0 0 1
[ 5] .gnu.version VERSYM 00000236 001236 000016 02 A 3 0 2
[ 6] .gnu.version_r VERNEED 0000024c 00124c 000020 00 A 4 1 4
note that the SHT_NOTE section has sh_addr 0 rather than 0xd4 (SIZE_OF_HEADERS),
sh_offset 0x1000 rather than 0 and there is quite a big gap between end of
.note.gnu.build-id section and .gnu.hash section.
In addition to being inefficient, e.g. ldconfig doesn't like such libraries.
The issue seems to be in gld*place_orphan, notes are placed on .interp hold,
but unlike executables shared libraries don't have .interp in their linker scripts.
As there aren't even any sections with similar flags like the .note section,
they end up being places right after the *ABS* section, but that's unfortunately
before the . = 0 + SIZE_OF_HEADERS; dot adjustment in the linker script.
The following patch cures this for me (and if we generate --build-id often,
it is probably a good idea anyway to put it there), but perhaps we should
do something with the orphan placement code as well.
2007-07-24 Jakub Jelinek <jakub@redhat.com>
* scripttempl/elf.sc: Add .note.gnu.build-id.
--- ld/scripttempl/elf.sc.jj 2007-07-24 10:07:02.000000000 +0200
+++ ld/scripttempl/elf.sc 2007-07-24 21:44:35.000000000 +0200
@@ -267,6 +267,7 @@ SECTIONS
${CREATE_SHLIB+${RELOCATING+. = ${SHLIB_TEXT_START_ADDR:-0} + SIZEOF_HEADERS;}}
${CREATE_PIE+${RELOCATING+. = ${SHLIB_TEXT_START_ADDR:-0} + SIZEOF_HEADERS;}}
${INITIAL_READONLY_SECTIONS}
+ .note.gnu.build-id : { *(.note.gnu.build-id) }
${TEXT_DYNAMIC+${DYNAMIC}}
.hash ${RELOCATING-0} : { *(.hash) }
.gnu.hash ${RELOCATING-0} : { *(.gnu.hash) }
Jakub
next reply other threads:[~2007-07-24 20:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-24 20:56 Jakub Jelinek [this message]
2007-07-24 23:10 ` Alan Modra
2007-07-24 23:36 ` Roland McGrath
2007-07-29 16:27 ` Alan Modra
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=20070724202224.GH4603@sunsite.mff.cuni.cz \
--to=jakub@redhat.com \
--cc=binutils@sources.redhat.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).