]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Pad and align sections in more cases
authorMatthew Malcomson <matthew.malcomson@arm.com>
Mon, 21 Feb 2022 13:18:25 +0000 (13:18 +0000)
committerMatthew Malcomson <matthew.malcomson@arm.com>
Mon, 21 Feb 2022 13:19:17 +0000 (13:19 +0000)
commit4a74b265839c80c669156e19948540214fd2d117
tree6e854bbf84e9fd96ff9b6ddebb4e8d3c9571cff2
parente23143023e2edd9ad8867e7d746eadf3c4ab377c
Pad and align sections in more cases

Before this change individual sections would not be padded or aligned if
there was no C64 code or if there were no capability GOT relocations in
the binary.  This meant that if we had a data-only PURECAP shared
library with a CAPINIT relocation in it pointing at something, then the
section that relocation pointed into would not be padded accordingly.

This patch changes this so that we look for sections which may need
individual padding if we see the PURECAP elf header flag, and if there
is a `srelcaps` section (i.e. the RELATIVE capability relocations).

We keep the behaviour that we do not adjust the size of sections unless
there is a static relocation pointing at a zero-sized symbol at that
section.  That is, we do not make any adjustment to try and handle
section padding in the case where other binaries would dynamically link
against such symbols.  We do this since the "symbol pointing to section
start implies spanning entire section" decision is a hack to enable some
linker script uses, and we don't want to extend it without a known
motivating example.

Finally, this patch ignores padding PCC bounds on PURECAP binaries if
there is no C64 code in this binary, but ensures that the PCC bounds are
made precise even if there are no static relocations in the file.
We could still get the current PCC and offset it using `adr` if there
are no static relocations, but without there being any C64 code there
will be no PCC to bound and hence we don't need the bounds on a
hypothetical PCC to be precise.
bfd/elfnn-aarch64.c