Re: CVS commit: src/sys/arch/x86/x86

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski <n54%gmx.com@localhost> 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