[PATCH] D86256: [libunwind] Make .eh_frame scanning/caching optional

[Ryan Prichard via Phabricator via llvm-commits]

rprichard added a comment.



> Just want to comment "Or use LLD, which automatically inserts the terminator" - the zero terminator CIE is to work around a glibc issue D46566 <https://reviews.llvm.org/D46566>

The need for the terminator seems more fundamental:

- In theory (and in the LSB5 spec), .eh_frame_hdr's search table is optional, or perhaps it could be incomplete? (e.g. see this mailing list post <https://sourceware.org/legacy-ml/binutils/2007-07/msg00066.html>)
- libgcc (and LLVM's libunwind) accommodate an incomplete/omitted search table by falling back to scanning .eh_frame.
- A PC might not be present in .eh_frame, so the unwinder needs to know when it reaches the end of .eh_frame.
- .eh_frame_hdr records the location of .eh_frame, but not the size.
- Therefore, a terminator is required.

If .eh_frame_hdr had also included the size of .eh_frame, then a terminator wouldn't be needed. My impression is that the terminator predates .eh_frame_hdr. e.g. The __register_frame_info function takes a pointer to the start of .eh_frame, but no size.

crtend.o normally provides the terminator, and bfd/gold appear to preserve it. So, if crtend.o isn't used, then .eh_frame is unterminated (e.g. PR36005). I noticed that bfd/gold remove a terminator if I try to add one before actual CIE/FDE records. LLD 6.0.0 seems to strip all terminators, including crtend.o's terminator, so the output is never terminated. Current LLD adds the terminator unconditionally, so the output is always terminated, even without crtend.o.

This Phabricator revision assumes that .eh_frame_hdr's search table is sufficient, and maybe it is, at least on some targets? I suspect the bfd/gold linkers issue a warning if they don't output a search table, and lld always outputs it.

Two more ways the search table can be omitted:

- With the gold linker, if .eh_frame has only a terminator, then the generated .eh_frame_hdr's table is omitted. LLD instead outputs a 0-entry search table.
- ld.bfd seems to omit the search table if it can't use relative relocations to refer to functions. I don't really understand what's happening there. Maybe HPPA is an example <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334112#15>?

Maybe the .eh_frame fallback scan can be skipped when .eh_frame_hdr has a search table. This should work as long as the table is never incomplete, and I suspect it'd make the terminator unnecessary most of the time.

For now, I think I'll work on a patch that simply removes the broken .eh_frame size calculation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86256/new/

https://reviews.llvm.org/D86256