diff options
| author | Adrian Vogelsgesang <avogelsgesang@salesforce.com> | 2022-09-14 03:21:34 -0700 |
|---|---|---|
| committer | Adrian Vogelsgesang <avogelsgesang@salesforce.com> | 2022-09-16 06:29:49 -0700 |
| commit | c9cffdde393f646acf62d6160e7fa6613e038508 (patch) | |
| tree | 84295b1b55a222f0f07fdabc23ef5d95e4c81708 /libcxx/src/filesystem/operations.cpp | |
| parent | c0ac3c114207fdef2e9cee295c85da7e843ac8d3 (diff) | |
| download | llvm-c9cffdde393f646acf62d6160e7fa6613e038508.zip llvm-c9cffdde393f646acf62d6160e7fa6613e038508.tar.gz llvm-c9cffdde393f646acf62d6160e7fa6613e038508.tar.bz2 | |
[libunwind] Fix usage of `_dl_find_object` on 32-bit x86
On 32-bit x86, `_dl_find_object` also returns a `dlfo_eh_dbase` address.
So far, compiling against a version of `_dl_find_object` which returns a
`dlfo_eh_dbase` was blocked using a `#if` + `#error`. This commit now
removes this compile time assertion and simply ignores the returned
`dlfo_eh_dbase`. All test cases are passing on a 32-bit build now.
According to https://www.gnu.org/software/libc/manual/html_node/Dynamic-Linker-Introspection.html,
`dlfo_eh_dbase` should be the base address for all DW_EH_PE_datarel
relocations. However, glibc/elf/dl-find_object.h says that eh_dbase
is the relocated DT_PLTGOT value. I don't understand how those two
statements fit together, but to fix 32-bit x86, ignoring `dlfo_eh_dbase`
seems to be good enough.
Fixes #57733
Differential Revision: https://reviews.llvm.org/D133846
Diffstat (limited to 'libcxx/src/filesystem/operations.cpp')
0 files changed, 0 insertions, 0 deletions