public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] non_got_ref after adjust_dynamic_relocs Date: Sun, 12 Nov 2017 10:14:00 -0000 [thread overview] Message-ID: <529fe20eeb0030ea5d653d0ebec433f9e3145874@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 529fe20eeb0030ea5d653d0ebec433f9e3145874 *** Author: Alan Modra <amodra@gmail.com> Branch: master Commit: 529fe20eeb0030ea5d653d0ebec433f9e3145874 non_got_ref after adjust_dynamic_relocs This patch was aimed at a FIXME in elf32-hppa.c, the ludicrous and confusing fact that non_got_ref after adjust_dynamic_relocs in that backend means precisely the inverse of what it means before adjust_dynamic_relocs. Before, when non_got_ref is set it means there are dynamic relocs, after, if non_got_ref is clear it means "keep dynamic relocs" and later, "has dynamic relocs". There is a reason why it was done that way.. Some symbols that may have dynamic relocations pre-allocated in check_relocs turn out to not be dynamic, and then are not seen by the backend adjust_dynamic_symbols. We want those symbols to lose their dynamic relocs when non-pic, so it's handy that non_got_ref means the opposite after adjust_dynamic_relocs. But it's really confusing. Most other targets, like ppc32, don't always set non_got_ref on non-GOT references that have dynamic relocations. This is because the primary purpose of non_got_ref before adjust_dynamic_relocs is to flag symbols that might need to be copied to .dynbss, and there are relocation types that may require dyn_relocs but clearly cannot have symbols copied into .dynbss, for example, TLS relocations. Why do we need a flag after adjust_dynamic_relocs to say "keep dynamic relocations"? Well, you can discard most unwanted dyn_relocs in the backend adjust_dynamic_relocs, and for those symbols that aren't seen by the backend adjust_dynamic_relocs, in allocate_dynrelocs based on a flag set by adjust_dynamic relocs, dynamic_adjusted. That doesn't solve all our difficulties though. relocate_section needs to know whether a symbol has dyn_relocs, and many targets transfer dyn_relocs to a weakdef if the symbol has one. The transfer means relocate_section can't test dyn_relocs itself and the weakdef field has been overwritten by that time. So non_got_ref is used to flag "this symbol has dynamic relocations" for relocate_section. Confused still? Well, let's hope the comments I've added help clarify things.. The patch also fixes a case where we might wrongly emit dynamic relocations in an executable for common and undefined symbols. * elf32-hppa.c (elf32_hppa_adjust_dynamic_symbol): Set non_got_ref to keep dyn_relocs, clear to discard. Comment. (allocate_dynrelocs): Always clear non_got_ref when clearing dyn_relocs in non-pic case. Invert non_got_ref test. Also test dynamic_adjusted and ELF_COMMON_DEF_P. Move code deleting dyn_relocs on undefined syms to handle for non-pic too. (elf32_hppa_relocate_section): Simplify test for non-pic dyn relocs. * elf32-ppc.c (ppc_elf_adjust_dynamic_symbol): Set non_got_ref to keep dyn_relocs, clear to discard. Comment. (allocate_dynrelocs): Always clear non_got_ref when clearing dyn_relocs in non-pic case. Invert non_got_ref test. Also test dynamic_adjusted and ELF_COMMON_DEF_P. Move code deleting dyn_relocs on undefined syms to handle for non-pic too. (ppc_elf_relocate_section): Simplify test for non-pic dyn relocs. * elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Discard dyn_relocs here. Don't bother setting non_got_ref. Comment. (allocate_dynrelocs): Delete special handling of non-pic ELFv2 ifuncs. Move code deleting dyn_relocs on undefined symbols to handle for non-pic too. Don't test non_got_ref. Do test dynamic_adjusted and ELF_COMMON_DEF_P.
next reply other threads:[~2017-11-12 10:14 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-12 10:14 sergiodj+buildbot [this message] 2017-11-12 10:14 ` Failures on Fedora-x86_64-m64, branch master sergiodj+buildbot 2017-11-12 10:29 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot 2017-11-12 10:33 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2017-11-12 10:39 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2017-11-12 10:43 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2017-11-12 10:49 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot 2017-11-12 11:00 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2017-11-12 11:20 ` Failures on Ubuntu-AArch64-native-gdbserver-m64, " sergiodj+buildbot 2017-11-12 11:24 ` Failures on Fedora-i686, " sergiodj+buildbot 2017-11-12 11:39 ` Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot 2017-11-12 11:49 ` Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot 2017-11-12 12:05 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2017-11-12 12:36 ` Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot
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=529fe20eeb0030ea5d653d0ebec433f9e3145874@gdb-build \ --to=sergiodj+buildbot@sergiodj.net \ --cc=gdb-testers@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).