> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski <n...@gmx.com> wrote:
>
> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least
> for the use of acpica (which still contains a fallback for Itanium
> without misaligned access, but not actively maintained).
>
> Linux uses a different approach and ships get_unaligned() and
> set_unaligned() macros and implements it on per ABI and CPU-basis.
In general, I get the utility of UBSan, but for these unaligned access issues,
an ad hoc approach like what was done in mpbios is the wrong way to go.
Here's my $0.02:
-- Define a set of standard unaligned-accessors/mutators. I propose:
uint16_t __unaligned_load16(const uint16_t *);
uint32_t __unaligned_load32(const uint32_t *);
uint64_t __unaligned_load64(const uint64_t *);
void __unaligned_store16(uint16_t *, uint16_t);
void __unaligned_store32(uint32_t *, uint32_t);
void __unaligned_store64(uint64_t *, uint64_t);
...and maybe you need to have another set for the signed value flavor, dunno.
(I guess probably, because you want to preserve the type information as much as
possible ... no casting.)
-- Implement them as static inlines in a suitable system header (<sys/types.h>,
maybe, although these types are <inttypes.h> types, yah? So, adjust the types
to __uint16_t or whatever as necessary). Decorate only these static inlines
with the "don't sanitize me" directives. Implementing them as inline functions
rather than macros has 2 benefits: avoids unintended multiple-evaluation of
arguments, allows the smallest possible "don't sanitize" footprint.
-- Implement 2 standard sets, one for __NO_STRICT_ALIGNMENT platforms, and one
for the strict-alignment case.
-- For changes like what would be needed in acpica, GET INPUT FROM THE UPSTREAM
as to how to integrate use of these macros, and preferably push the changes to
the upstream FIRST so that we can simply import them in a regular update.
-- thorpej
