[PATCH] D87750: [libunwind][DWARF] Fix end of .eh_frame calculation

[Ryan Prichard via Phabricator via llvm-commits]

rprichard added a comment.

An alternative to D86256 <https://reviews.llvm.org/D86256>.

It adds another field to UnwindInfoSections, so the cache will use more memory:

- This can obviously be avoided, because `dwarf_section_length` is now always initialized to `UINTPTR_MAX` when `_LIBUNWIND_USE_DL_ITERATE_PHDR` and `_LIBUNWIND_SUPPORT_DWARF_INDEX` are defined.
- Even the `dwarf_section` field is unnecessary if we're willing to decode the .eh_frame_hdr on a cache hit. (The unwinder already decodes it again, later, because most of the fields aren't stored in UnwindInfoSections. I think decoding is fairly cheap.)
- The `dwarf_index_section_length` field isn't really used much, currently. It's used to bounds-check fields if they use LEB encodings. (They probably don't). It *could* be used to do more bounds checking, though.
- If this matters, I think it can be fixed later.

After disentangling `dso_length` from `dwarf_section_length`, it should be easy to combine the DWARF and EHABI versions of `findUnwindSectionsByPhdr` in AddressSpace.hpp. Only the `PT_GNU_EH_FRAME` vs `PT_ARM_EXIDX` bits should be different. I assume that could be a later patch.



================
Comment at: libunwind/src/AddressSpace.hpp:465
   }
-  cbdata->sects->dwarf_section_length = 0;
   return 0;
----------------
FWIW: None of the `UnwindInfoSections` fields are used if `LocalAddressSpace::findUnwindSections` returns false. I removed this line because it's inconsistent to clear only this field, and only for the dl_iterate_phdr codepath.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87750