public inbox for binutils-cvs@sourceware.org help / color / mirror / Atom feed
From: Alan Modra <amodra@sourceware.org> To: bfd-cvs@sourceware.org Subject: [binutils-gdb/binutils-2_39-branch] PR29355, ld segfaults with -r/-q and custom-named section .rela* Date: Tue, 12 Jul 2022 03:01:31 +0000 (GMT) [thread overview] Message-ID: <20220712030131.6F9913858D33@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=23b1320eb51e6c52608074526bc9833ffa4129ec commit 23b1320eb51e6c52608074526bc9833ffa4129ec Author: Alan Modra <amodra@gmail.com> Date: Tue Jul 12 10:51:52 2022 +0930 PR29355, ld segfaults with -r/-q and custom-named section .rela* The bug testcase uses an output section named .rel or .rela which has input .data sections mapped to it. The input .data section has relocations. When counting output relocations SHT_REL and SHT_RELA section reloc_count is ignored, with the justification that reloc sections themselves can't have relocations and some backends use reloc_count in reloc sections. However, the test wrongly used the output section type (which normally would match input section type). Fix that. Note that it is arguably wrong for ld to leave the output .rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc sections are written to it, but I'm not going to change that since it might be useful to hand-craft relocs in a data section that is then written to a SHT_REL/SHT_RELA output section. PR 29355 * elflink.c (bfd_elf_final_link): Use input section type rather than output section type to determine whether to exclude using reloc_count from that section. (cherry picked from commit 35c5dcc666082f0edf6dd559e46b98d0e7986a2e) Diff: --- bfd/elflink.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bfd/elflink.c b/bfd/elflink.c index dcafac32800..2b1450fa4e1 100644 --- a/bfd/elflink.c +++ b/bfd/elflink.c @@ -12413,8 +12413,10 @@ bfd_elf_final_link (bfd *abfd, struct bfd_link_info *info) && elf_symtab_shndx_list (sec->owner) != NULL) max_sym_shndx_count = sym_count; - if (esdo->this_hdr.sh_type == SHT_REL - || esdo->this_hdr.sh_type == SHT_RELA) + esdi = elf_section_data (sec); + + if (esdi->this_hdr.sh_type == SHT_REL + || esdi->this_hdr.sh_type == SHT_RELA) /* Some backends use reloc_count in relocation sections to count particular types of relocs. Of course, reloc sections themselves can't have relocations. */ @@ -12432,8 +12434,6 @@ bfd_elf_final_link (bfd *abfd, struct bfd_link_info *info) else if (bed->elf_backend_count_relocs) reloc_count = (*bed->elf_backend_count_relocs) (info, sec); - esdi = elf_section_data (sec); - if ((sec->flags & SEC_RELOC) != 0) { size_t ext_size = 0;
reply other threads:[~2022-07-12 3:01 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=20220712030131.6F9913858D33@sourceware.org \ --to=amodra@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: linkBe 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).