Support .sframe #1511
Description
This issue/feature request was submitted by email:
GNU as when passed an option --gsframe generates SFrame sections. These sections are named .sframe and are of section type SHT_GNU_SFRAME starting GNU Binutils 2.45 (They were of type SHT_PROGBITS, switching to SHT_GNU_SFRAME was the course correction done in Binutils 2.45 release).
These sections have a layout such that an abiding linker will need to merge the sections, simply concatenating them is not correct output.
LLVM support for SFrame sections is ongoing.
Specification (SFrame version 2, Errata 1):
https://sourceware.org/binutils/docs/sframe-spec.html
https://sourceware.org/binutils/docs/sframe-spec.pdf
Wiki:
https://sourceware.org/binutils/wiki/sframe
On systems which may consider enabling SFrame by default in future, (SFrame) unaware linkers may start giving users some pain and incorrect SFrame section data in the output. Recently, we ran into an issue: llvm/llvm-project#156667. The core issue in 156667 is that SFrame sections need to be merged, and an abiding linker must them remove SFrame metadata for discarded symbols.
In abstract terms, SFrame metadata holds stack tracing information for functions in the binary. I see that the current behavior in mold is to concatenate the SFrame sections. These sections need to be "merged" by the linker placing the SFrame header first, followed by all SFrame function related metadata (SFrame FDEs), followed by SFrame PC range related metadata (SFrame FREs).