public inbox for binutils-cvs@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@sourceware.org>
To: bfd-cvs@sourceware.org
Subject: [binutils-gdb] Arm64/ELF: accept relocations against STN_UNDEF
Date: Fri, 31 Mar 2023 06:19:08 +0000 (GMT)	[thread overview]
Message-ID: <20230331061908.73EB53858D20@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=af9eb2ee1b10caa89e1c603cd484bc025e71f4fd

commit af9eb2ee1b10caa89e1c603cd484bc025e71f4fd
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Mar 31 08:15:53 2023 +0200

    Arm64/ELF: accept relocations against STN_UNDEF
    
    While only a secondary issue there, the testcase of PR gas/27212 exposes
    an oversight in relocation handling: Just like e.g. Arm32, which has a
    similar comment and a similar check, relocations against STN_UNDEF have
    to be permitted to satisfy the ELF spec.

Diff:
---
 bfd/elfnn-aarch64.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
index c4db1e6f168..c23cbd3601a 100644
--- a/bfd/elfnn-aarch64.c
+++ b/bfd/elfnn-aarch64.c
@@ -6946,8 +6946,12 @@ elfNN_aarch64_relocate_section (bfd *output_bfd,
 
 	  /* An object file might have a reference to a local
 	     undefined symbol.  This is a daft object file, but we
-	     should at least do something about it.  */
+	     should at least do something about it.  NONE and NULL
+	     relocations do not use the symbol and are explicitly
+	     allowed to use an undefined one, so allow those.
+	     Likewise for relocations against STN_UNDEF.  */
 	  if (r_type != R_AARCH64_NONE && r_type != R_AARCH64_NULL
+	      && r_symndx != STN_UNDEF
 	      && bfd_is_und_section (sec)
 	      && ELF_ST_BIND (sym->st_info) != STB_WEAK)
 	    (*info->callbacks->undefined_symbol)

                 reply	other threads:[~2023-03-31  6:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20230331061908.73EB53858D20@sourceware.org \
    --to=jbeulich@sourceware.org \
    --cc=bfd-cvs@sourceware.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).