On Tue, Feb 27, 2018 at 10:04:15PM +0100, Mark Kettenis wrote:
> The "new" AAPCS-based ABI that we have been using on armv7 for a while
> now requires various 64-bit types to be aligned on an 8-byte boundary.
> Unfortunately we didn't realize this when we switched and didn't
> adjust the definition of _ALIGNBYTES accordingly. The diff below
> fixes that.
>
> However, this triggers a flag day. It changes the CMSG ABI, which
> means that file descriptor passing breaks as soon as you boot a new
> kernel with old userland. That sucks since many of our daemons use
> file descriptor passing, including sshd. Can we deal with yet another
> ABI break on armv7? I'm not sure the ports builders have recovered
> from the switch to clang yet...
We need to bite the bullet here. Having _ALIGNBYTES wrong could lead to all
kinds of hard to debug problems way worse than a flag day.
-Otto
>
>
> Index: arch/arm/include/_types.h
> ===================================================================
> RCS file: /cvs/src/sys/arch/arm/include/_types.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 _types.h
> --- arch/arm/include/_types.h 26 Sep 2015 16:01:00 -0000 1.17
> +++ arch/arm/include/_types.h 27 Feb 2018 20:54:05 -0000
> @@ -51,7 +51,7 @@ typedef struct label_t {
> * This does not reflect the optimal alignment, just the possibility
> * (within reasonable limits).
> */
> -#define _ALIGNBYTES (sizeof(int) - 1)
> +#define _ALIGNBYTES (sizeof(double) - 1)
> #define _STACKALIGNBYTES 7
> #define _ALIGN(p) (((unsigned long)(p) + _ALIGNBYTES) &
> ~_ALIGNBYTES)
> #define _ALIGNED_POINTER(p,t) ((((unsigned long)(p)) & (sizeof(t) -
> 1)) == 0)
