summaryrefslogtreecommitdiff
path: root/bfd/elfxx-tilegx.c
diff options
context:
space:
mode:
authorMatthew Malcomson <matthew.malcomson@arm.com>2022-11-04 10:01:53 +0000
committerMatthew Malcomson <matthew.malcomson@arm.com>2022-11-04 10:03:08 +0000
commit816fc4e7c2e808384a3eae81844c76c908a1f8a3 (patch)
treeabf78328039f0f6e8badf5f3e4077ced0a99a5e2 /bfd/elfxx-tilegx.c
parentf8c6b621d4ed4cf68f595845f0222530f8d00de0 (diff)
downloadbinutils-gdb-816fc4e7c2e808384a3eae81844c76c908a1f8a3.tar.gz
Fix tests after rebase of 36b6002396d onto 8504495ada4
When we started to account for function stubs when determining our PCC bounds and section bounds we stopped including padding to make PCC bounds precise in the highest section that should be included in the PCC range. Instead we put such padding *after* that section. Our patch handling IFUNC's was written in parallel, and its testcases were using the previous setup (where PCC padding was included in the last section). Hence when calculating a fragment that we should see in our testcase we took the highest address in the last RELRO section. After the application of both patches that approach no longer works. With the new mechanism for padding there is no longer in general a guarantee that any value in the section table could correspond to the PCC bounds (since the alignment of the first writeable section could be high enough such that the PCC bounds are somewhere between the end of the last RELRO section and the start of the first WRITE section). However for all these testcases the start of the first WRITE section seems good enough to not be flaky.
Diffstat (limited to 'bfd/elfxx-tilegx.c')
0 files changed, 0 insertions, 0 deletions