[ELF] Support DW_EH_PE_sdata8 encoding in .eh_frame_hdr (#179089)HEADmain

Currently, both GNU ld and lld only support
`table_enc = DW_EH_PE_datarel | DW_EH_PE_sdata4` for .eh_frame_hdr.
When a table entry exceeds the 32-bit range, we can use
`DW_EH_PE_sdata8` instead of reporting an error
(https://reviews.llvm.org/D49607 introduced the "PC offset is too large"
error). This is useful for certain large executables.

This patch auto-detects when 64-bit encoding is needed and upgrades
the encoding accordingly. We use DW_EH_PE_sdata8 when either a table
entry or eh_frame_ptr exceeds the 32-bit range.

Technically, eh_frame_ptr could remain sdata4 when only table entries
require sdata8, but there is little value in this flexibility since
.eh_frame/.eh_frame_hdr distance is a much less strict constraint than
.text/.eh_frame_hdr distance.

The implementation caches FDE data in EhFrameHeader during
updateAllocSize and reuses it in writeTo.

Previously, `EhFrameSection::getFdePc` was used to read the
`initial_location` value from .eh_frame FDEs. Since the value equals the
relocated symbol's VA for all cases that matter, we now obtain the value
directly and simplify the implementation.

Also update the outdated comment about sorting the FDE list; the ICF
case mentioned there no longer applies after
https://reviews.llvm.org/D116093.

In the new test eh-frame-hdr-sdata8.s, 3.lds is carefully crafted to
ensure that .eh_frame_hdr size requires fixed-point iteration (to test
`updateAllocSize`). This is also groundwork for compact unwind support
similar to Mach-O `__unwind_info`.

Close #172777

0 files changed, 0 insertions, 0 deletions