Re: [PATCH 07/24] ARM64:ILP32: Use the same size and layout of the signal structures for ILP32 as for LP64.

[Catalin Marinas]

On Sat, May 24, 2014 at 12:02:02AM -0700, Andrew Pinski wrote:
> diff --git a/arch/arm64/include/uapi/asm/siginfo.h b/arch/arm64/include/uapi/asm/siginfo.h
> index 5a74a08..1a6aa32 100644
> --- a/arch/arm64/include/uapi/asm/siginfo.h
> +++ b/arch/arm64/include/uapi/asm/siginfo.h
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (C) 2012 ARM Ltd.
> + * Copyright (C) 2014 Cavium Inc.
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -18,6 +19,26 @@
>  
>  #define __ARCH_SI_PREAMBLE_SIZE	(4 * sizeof(int))
>  
> +#ifdef __ILP32__

Does the compiler define __ILP32__ or it just undefined __LP64__.
Anyway, maybe we should have some consistency and only use one in all
places.

> +# ifdef __AARCH64EB__
> +#  define __SIGINFO_INNER(type, field)		\
> +		int __pad#field;		\
> +		type field
> +# else
> +#  define __SIGINFO_INNER(type, field)		\
> +		type field;			\
> +		int __pad#field
> +# endif
> +
> +# undef __SIGINFO_VOIDPOINTER
> +# define __SIGINFO_VOIDPOINTER(field)		\
> +		__SIGINFO_INNER(void __user*, field)
> +# undef __SIGINFO_BAND
> +
> +# define __SIGINFO_BAND(field)			\
> +	__SIGINFO_INNER(long, field)
> +#endif
> +
>  #include <asm-generic/siginfo.h>
>  
>  #endif

Do the above give us the correct alignment for the _sifields union in
siginfo? Or we get it as a side-effect of some other structure member
forcing 64-bit alignment?

> diff --git a/arch/arm64/include/uapi/asm/signal.h b/arch/arm64/include/uapi/asm/signal.h
> index 8d1e723..d90d53b 100644
> --- a/arch/arm64/include/uapi/asm/signal.h
> +++ b/arch/arm64/include/uapi/asm/signal.h
> @@ -19,6 +19,38 @@
>  /* Required for AArch32 compatibility. */
>  #define SA_RESTORER	0x04000000
>  
> +/* For ILP32, sigset should be the same size fields as LP64 so use
> +   unsigned long long. */
> +#ifdef __ILP32__
> +#define __SIGSET_INNER_TYPE __extension__ unsigned long long
> +#define _NSIG_BPW 64
> +
> +# ifdef __AARCH64EB__
> +#  define __SIGNAL_INNER(type, field)		\
> +	__extension__ struct {			\
> +		int __pad_##field;		\
> +		type field;			\
> +	} __attribute__((aligned(8)))
> +# else
> +#  define __SIGNAL_INNER(type, field)		\
> +	__extension__ struct {			\
> +		type field;			\
> +		int __pad_##field;		\
> +	} __attribute__((aligned(8)))
> +# endif
> +
> +# define __SIGACTION_HANDLER(field)		\
> +	__SIGNAL_INNER(__sighandler_t, field)
> +
> +
> +#define __SIGACTION_FLAGS(field)		\
> +	__extension__ unsigned long long field
> +
> +#define __SIGACTION_RESTORER(field)		\
> +	__SIGNAL_INNER(__sigrestore_t, field)
> +
> +#endif
> +
>  #include <asm-generic/signal.h>
>  
>  #endif

I haven't seen any UAPI header using __extension__. Is this allowed? I
assume we should be allowed to use the exported kernel headers with
non-gcc compilers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/