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

Mon Sep 14 17:17:04 PDT 2020

rprichard added a comment.

In D86256#2270331 <https://reviews.llvm.org/D86256#2270331>, @mstorsjo wrote:

> The commit description talks about making the caching optional, but I don't really see that aspect in the patch - or maybe I'm just not studying it closely enough?

Oh, by optional, I just meant that the .eh_frame scanning and caching are both controlled by the new `_LIBUNWIND_SUPPORT_DWARF_SECTION` macro, which is left off for some targets.

In D86256#2255830 <https://reviews.llvm.org/D86256#2255830>, @rprichard wrote:

> The Linux ABI Extensions spec <https://raw.githubusercontent.com/wiki/hjl-tools/linux-abi/linux-abi-draft.pdf> describes the binary search table of .eh_frame_hdr as optional, so maybe falling back to .eh_frame scanning could be necessary to accommodate some ELF files? I wonder what situation results in an omitted search table. ld.bfd does have code for outputting .eh_frame_hdr without a search table.

It looks like both ld.bfd and ld.gold have code paths that output an .eh_frame_hdr without a search table. This can happen if they're not able to parse .eh_frame. AFAICT, LLD always outputs the search table (EhFrameHeader::write <https://github.com/llvm/llvm-project/blob/7b391245d8eab16d1dfabde9f67a97fa9809ab49/lld/ELF/SyntheticSections.cpp#L2975-L2999>), and aborts if it can't parse .eh_frame. One example of this: If a CIE has an unrecognized augmentation code, then the linker may be unable to parse the `R` code, and without that, it can't read the FDE `initial_location` field, because the `R` code specifies its encoding. LLD avoids this problem by aborting if it can't read the `R` code (EhReader::getFdeEncoding <https://github.com/llvm/llvm-project/blob/d30d46193876102a6bc99b527dfaf79be4b09515/lld/ELF/EhFrame.cpp#L183-L201>).

libgcc appears to fall back to scanning .eh_frame if .eh_frame_hdr doesn't have the FDE, and it can scan beyond the end of the segment containing the .eh_frame section, if the section doesn't end with a terminator.

Perhaps a more conservative fix for PR46829 is to match libgcc's behavior here, by disabling the end-of-section tracking for dl_iterate_phdr. e.g. by setting dwarf_section_length to -1. In that case, then PR36005's true fix is to link against a crtend.o with the .eh_frame terminator. (Or use LLD, which automatically inserts the terminator.)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86256