[PATCH] D133846: [libunwind] Fix usage of `_dl_find_object` on 32-bit x86

Adrian Vogelsgesang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 15 07:04:56 PDT 2022


avogelsgesang added reviewers: MaskRay, compnerd.
avogelsgesang added subscribers: MaskRay, compnerd.
avogelsgesang added a comment.
Herald added a subscriber: StephenFan.

@MaskRay and @compnerd could I get a review from you on this change, please :)

Not sure if this is the correct approach. As an alternative solution, I could also imagine to pass through the `dlfo_eh_dbase` to the `LocalAddressSpace::getEncodedP` function.

Afaict, libunwind currently only correctly supports `dlfo_eh_dbase == dlfo_map_start` becase:

- Looking at `LocalAddressSpace::getEncodedP`, we see that `DW_EH_PE_datarel` is only supported if `datarelBase` is set.
- The only places which passes a non-zero `datarelBase` are `EHHeaderParser<A>::{decodeEHHdr,findFDE}`. Both those invocations pass `ehHdrStart` as `datarelBase`.
- The invocations of `EHHeaderParser<A>::{decodeEHHdr,findFDE}` pass `info.dwarf_index_section` as `ehHdrStart`.
- `info.dwarf_index_section` is identical to `dlfo_map_start`.

At least on Linux 32-bit x86, I `dlfo_eh_dbase` is not equal to `dlfo_map_start`, though. I guess the current change works because `DW_EH_PE_datarel` is not actually used...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133846



More information about the llvm-commits mailing list