Attempt to make libcxxrt's dwarf_eh work with strict alignment

[dim]

Summary

In the thread starting here:
https://lists.freebsd.org/pipermail/freebsd-arm/2015-January/009998.html

Daisuke Aoyama describes how libcxxrt does not properly handle parsing
an exception table on an RPi (e.g. arm). This is because parts of
dwarf_eh.h read 16 bit, 32 bit and 64 bit values directly from possibly
unaligned addresses.

He posted a workaround patch here:
https://lists.freebsd.org/pipermail/freebsd-arm/2015-January/010014.html

but it is incomplete, as it does not handle the 16 and 64 bit cases, nor
does it work for other architectures with strict alignment.

Here is another attempt, where I put the reading of different sized
objects into their own static inline functions, and try to handle
alignment and endianness properly.

This seems to work on i386 and amd64, but I can't test arm and/or mips
myself.

Also, I now assume the NO_STRICT_ALIGNMENT and LITTLE_ENDIAN__
macros are available, and works as expected. That shoudl probably be
refined before we send this upstream. Unfortunately these are both
non-standard, and there seems to be no reliable way of determining them
portably.

Test Plan

Build and install on various arches, with and without strict alignment,
and with little and big endian ordering.

[imp]

I'd just do a memcpy version of the read routines. All this #ifdef junk is insane. It will do the right thing every time.

contrib/libcxxrt/dwarf_eh.h

154–163

uint16_t res;
memcpy(&res, reinterpret_cast<void *>(*data), sizeof(uint16_)t);

would be better.

176–188

see above for less insane code.

200–221

see above for less insane code.

[imp]

ah, forgot that LITTLE_ENDIAN isn't universally available (or didn't used to be, that may have changed).

contrib/libcxxrt/dwarf_eh.h

157

Also, LITTLE_ENDIAN isn't universally available (or hasn't been in the past).

But there's no need since a memcpy version doesn't need it or NO_STRICT_ALIGNMENT.

[dim]

contrib/libcxxrt/dwarf_eh.h

157

But memcpy doesn't handle endianness? Or are we assuming the data has been written in the same endianness as the machine is using?

[imp]

It doesn't matter because the code already assumed endianness with its preprocessor LITTLE_ENDIAN. The prior code assumed native endinaness as well, since it just did the cast.

memcpy is exactly what you want to replace the old code with.

[dim]

Replacing the assignments with memcpy. This is indeed much more
concise, thanks Warner. :-)

[dim]

Simplify even more, by getting rid of the unnecessary 'v' variable.

[bapt]

tested successfully with kyua which was triggering the bug

[dim]

Closed by commit rS279307 (authored by @dim).