public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: binutils@sourceware.org
Cc: mjw@fedoraproject.org, amulhern@redhat.com
Subject: RFC: Can static executables contain relocations against symbols ?
Date: Wed, 29 Mar 2023 15:39:46 +0100	[thread overview]
Message-ID: <87v8ijmxjh.fsf@redhat.com> (raw)

Hi Guys,

  Can static executables contain relocations against symbols ?

  This question has come up in Fedora as part of the investigation into
  a problem linking some binaries compiled with the Rust compiler:

https://bugzilla.redhat.com/show_bug.cgi?id=2166149

  The issue appears to be that static-pie executables are being created
  with a .rela.got section that has an sh_link field set to point to the
  .symtab section.  This in turns means that running strip on the
  executables will not remove the .symtab section, which is then being
  flagged as an error by the build system.

  The problem is not happening for x86_64 binaries because they contain
  a .dynsym section, and the code in bfd/elf.c:assign_section_numbers
  will preferentially use that section if it exists.  (It is not clear
  to me *why* x86_64 static pie binaries contain a .dynsym section, but
  they do).

  It is possible for static executables to contain relocations - for
  ifuncs for example - but I think that they should always be absolute.
  So my question is: is it safe to set the sh_link field for relocation
  sections in static executables to 0 ?

  The attached patch is a suggestion for the change I am considering...

  Thoughts ?
  
Cheers
  Nick

diff --git a/bfd/elf.c b/bfd/elf.c
index 45e53640e8f..0b5c8c79fd6 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -3884,7 +3884,25 @@ assign_section_numbers (bfd *abfd, struct bfd_link_info *link_info)
 		d->this_hdr.sh_link = elf_section_data (s)->this_idx;
 	    }
 	  if (d->this_hdr.sh_link == 0)
-	    d->this_hdr.sh_link = elf_onesymtab (abfd);
+	    {
+	      /* In general static executables should not need relocations.
+		 There are exceptions however, for ifuncs for example, but
+		 in these cases the relocations should not need any symbols.
+		 Hence it should be safe to leave the sh_link field as 0.
+		 Not setting sh_link allows the symbol table to be stripped
+		 from the executable, which is a desirable trait.
+
+		 FIXME: Should we scan the relocations first to make sure
+		 that there are no symbol references ?  */
+	      if (link_info != NULL
+		  && bfd_link_executable (link_info)
+		  && (abfd->flags & DYNAMIC) == 0)
+		;
+	      else
+		d->this_hdr.sh_link = elf_onesymtab (abfd);
+	    }
 
 	  s = elf_get_reloc_section (sec);
 	  if (s != NULL)


             reply	other threads:[~2023-03-29 14:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 14:39 Nick Clifton [this message]
2023-03-29 15:47 ` Mark Wielaard
2023-03-29 16:00 ` Michael Matz
2023-03-30  1:22 ` Alan Modra
2023-03-30  4:54   ` Alan Modra
2023-03-30  8:57     ` Nick Clifton
2023-03-30  9:12       ` 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=87v8ijmxjh.fsf@redhat.com \
    --to=nickc@redhat.com \
    --cc=amulhern@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=mjw@fedoraproject.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 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).