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