libc++abi: Make the .eh_frame_hdr code work on FreeBSD as well

[ed]

Summary

We currently only include <link.h> on CloudABI and Linux. We can enable it on FreeBSD as well, as it also supports the dl_iterate_phdr() function that's provided by <link.h>.

FreeBSD, however, does not provide the ElfW() macro. Instead, the host-specific ELF datastructures are named just Elf_XXX in addition to the host-independent Elf32_XXX and Elf64_XXX types.

[ed]

Saleem, could you please take a look at this change?

Thanks,
Ed

[compnerd]

src/Unwind/AddressSpace.hpp

60

This part is safe.

71

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?

[ed]

src/Unwind/AddressSpace.hpp

71

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:

http://linux.die.net/man/3/dl_iterate_phdr

[jroelofs]

src/Unwind/AddressSpace.hpp

71

@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>.

[compnerd]

src/Unwind/AddressSpace.hpp

67

I tend to prefer #if !defined() as it makes it easier to extend in the future if necessary.

70

It would be nice if you renamed ElfW2 and ElfW3 to something more generic (GLUE, GLUE_EXPANDED?). They don't have anything to do with ELF specifically.

71

Ah, right, this would be run on the remote thread. Fair enough.

[ed]

src/Unwind/AddressSpace.hpp

67

Done!

70

I looked into it a bit more closely and it looks like we can avoid it altogether.

Systems that don't provide ElfW() seem to provide additional typedefs so that we can just Elf_XXX. There is no need to put the INTPTR_WIDTH in between. Do you think that looks all right?

[emaste]

LGTM

src/Unwind/AddressSpace.hpp

 #endif // !defined(_LIBUNWIND_IS_BAREMETAL)
 #endif  // LIBCXXABI_ARM_EHABI
 
-#if defined(__CloudABI__) || defined(__linux__)
+#if defined(__CloudABI__) || defined(__FreeBSD__) || defined(__linux__)
 #if _LIBUNWIND_SUPPORT_DWARF_UNWIND && _LIBUNWIND_SUPPORT_DWARF_INDEX
 #include <link.h>
+// Macro for machine-independent access to the ELF program headers. This
+// macro is not available on some systems (e.g., FreeBSD). On these
+// systems the data structures are just called Elf_XXX. Define ElfW()
+// locally.
+#if !defined(ElfW)
+#define ElfW(type) Elf_##type
+#endif
 #include "EHHeaderParser.hpp"
 #endif
 #endif