public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

             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).