]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Use htab->c64_rel more, do not use GOT_CAP
authorMatthew Malcomson <matthew.malcomson@arm.com>
Fri, 1 Jul 2022 10:48:52 +0000 (11:48 +0100)
committerJohn Baldwin <jhb@FreeBSD.org>
Thu, 1 Sep 2022 23:08:20 +0000 (16:08 -0700)
commitc3f22fe190a2232184573da3d36cb55634259867
tree106c0da892d02d470523902c4ca9b03602c83bb4
parent58969269b95669bb05d386ae8456cdbb5478033f
Use htab->c64_rel more, do not use GOT_CAP

Each symbol that has a reference in the GOT has an associated got_type.
For capabilities we currently have a new got_type of GOT_CAP for
capability entries in the GOT.

We do not allow capability entries in the GOT for an A64 (or hybrid)
binary, and only allow capability entries in the GOT for a purecap
binary.  Hence there is no need to maintain a per-symbol indication of
whether the associated GOT entry for this symbol is a capability or not.

There is already an existing flag on the hash table to indicate whether
the GOT contains capabilities or addresses.  We can replace every use of
the existing GOT_CAP with a check of this flag.

Doing such a transformation means we can not express an invalid state
(there is no longer any way to express a GOT which contains some
addresses and some capabilities).  It also solves a bug where we
introduce a PLT to be the canonical address of a function after having
seen a R_AARCH64_LDST128_ABS_LO12_NC relocation.  The existing manner of
deciding whether an entry in the GOT should be a capability or address
based on the relocation we generated it from could not work in a binary
when we only have this relocation.  It should be determined based on the
flags of the input object files we saw (i.e. are these purecap object
files or not).

N.b. this also fixes an observed problem that could have been fixed in
the existing regime.  In this case the JUMP_SLOT of a PLT entry added to
be the canonical address of a function which was addressed directly in
code (with both a Morello and AArch64 relocation) had got_type of
GOT_UNKNOWN (because it was simply not marked) and hence
elfNN_aarch64_create_small_pltn_entry was generating an AArch64
relocation because the GOT entry was not GOT_CAP.

This patch also adjusts the "should this GOT contain capabilities" flag
to report yes/no based on the EF_AARCH64_CHERI_PURECAP flag of the
inputs rather than based on whether we've seen any morello relocations
pointing into the GOT.
NOTE:  We do not remove the existing times where we set this flag based
on MORELLO relocations.  This is left for a future patch when we look
into the handling of hybrid code and the GOT.

N.b. this required two changes in the testsuite.
morello-capinit.d required updating since the size of the GOT section
was previously incorrectly calculated.  There is no GOT relocation in
this testcase, which meant that the existing method of finding the size
of the dummy first GOT entry was incorrect (gave the size of an AArch64
entry).  Since the size of the GOT is now different the PCC bounds is
now different, and we hence need to update the values checking for the
PCC bounds in this testcase.

We take this opportunity to make the testcase more robust by using the
new record/check testsuite feature.  This means the testcase now passes
on other targets (i.e. both bare-metal and for none-linux).

emit-relocs-morello.d had a minor change for the same reason.  Since the
alignment requirement of the GOT changed this changed the start position
too.  When the start position changed objdump decided not to output an
extra line of 0000000.
bfd/elfnn-aarch64.c
ld/testsuite/ld-aarch64/emit-relocs-morello.d
ld/testsuite/ld-aarch64/morello-capinit.d