[PATCH] libc++abi: Make the .eh_frame_hdr code work on FreeBSD and CloudABI as well
jonathan at codesourcery.com
Tue Mar 17 08:21:32 PDT 2015
Comment at: src/Unwind/AddressSpace.hpp:71
@@ -63,1 +70,3 @@
+#define ElfW3(width, type) Elf##width##_##type
> compnerd wrote:
> > Hmm..Im not sure that this is the best way to approach this. What if you want to do remote unwinding, where your host is 32-bit and your remote is 64-bit or vice-versa. This breaks in that case, as you are using `__INTPTR_WIDTH__`. Or am I overlooking something?
> This piece of code always has to be executed on the target. This macro is simply needed to fulfil the contract of `dl_iterate_phdr()`. This function is executed on the target system to obtain the address of the ELF program headers of the running process.
> Using a width unequal to `__INTPTR_WIDTH__` wouldn't make any sense. In fact, it would only generate compiler errors, for the reason that `struct dl_phdr_info::dlpi_phdr` is defined as a `const ElfW(Phdr) *`. See the following man page for details:
@compnerd: Does the remote unwinding stuff even build? I don't see a declaration for `template <typename T> class Pointer32;`, nor for `class LittleEndian;`...
Either way, I think @ed is right here: no matter the pointer size of the target process, if we link against `dl_iterate_phdr()`, we have to use the pointer size for *this* process, not the pointer size for the *other* process. This will work unless the ElfW's are used in the interface between `LocalAddressSpace` and `OtherAddressSpace<Foo>`.
More information about the cfe-commits