Hello Scott, Andre, Tyler,
On Mon, 2 Feb 2026 at 05:48, <[email protected]> wrote:
>
> From: Scott Mitchell <[email protected]>
>
> Add __rte_may_alias attribute to unaligned_uint{16,32,64}_t typedefs
> to prevent GCC strict-aliasing optimization bugs. GCC has a bug where
> it incorrectly elides struct initialization when strict aliasing is
> enabled, causing reads from uninitialized memory.
>
> Add __rte_aligned(1) attribute to unaligned_uint{16,32,64}_t typedefs
> which allows for safe access at any alignment. Without this, accessing
> a uint16_t at an odd address is undefined behavior. Without this
> UBSan detects `UndefinedBehaviorSanitizer: undefined-behavior`.
>
> Fixes: 7621d6a8d0bd ("eal: add and use unaligned integer types")
> Cc: [email protected]
>
> Signed-off-by: Scott Mitchell <[email protected]>
[snip]
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 573bf4f2ce..7b36966019 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -121,16 +121,42 @@ extern "C" {
> #define __rte_aligned(a) __attribute__((__aligned__(a)))
> #endif
>
> -#ifdef RTE_ARCH_STRICT_ALIGN
> -typedef uint64_t unaligned_uint64_t __rte_aligned(1);
> -typedef uint32_t unaligned_uint32_t __rte_aligned(1);
> -typedef uint16_t unaligned_uint16_t __rte_aligned(1);
> +/**
> + * Macro to mark a type that is not subject to type-based aliasing rules
> + */
> +#ifdef RTE_TOOLCHAIN_MSVC
> +#define __rte_may_alias
> #else
> -typedef uint64_t unaligned_uint64_t;
> -typedef uint32_t unaligned_uint32_t;
> -typedef uint16_t unaligned_uint16_t;
> +#define __rte_may_alias __attribute__((__may_alias__))
> #endif
>
> +/* Unaligned types implementation notes:
> + * __rte_aligned(1) - Reduces alignment requirement to 1 byte, allowing
> + * these types to safely access memory at any address.
> + * Without this, accessing a uint16_t at an odd address
> + * is undefined behavior (even on x86 where hardware
> + * handles it).
> + *
> + * __rte_may_alias - Prevents strict-aliasing optimization bugs where
> + * compilers may incorrectly elide memory operations
> + * when casting between pointer types.
> + */
> +
> +/**
> + * Type for safe unaligned u64 access.
> + */
> +typedef __rte_may_alias __rte_aligned(1) uint64_t unaligned_uint64_t;
> +
> +/**
> + * Type for safe unaligned u32 access.
> + */
> +typedef __rte_may_alias __rte_aligned(1) uint32_t unaligned_uint32_t;
> +
> +/**
> + * Type for safe unaligned u16 access.
> + */
> +typedef __rte_may_alias __rte_aligned(1) uint16_t unaligned_uint16_t;
> +
> /**
> * @deprecated
> * @see __rte_packed_begin
> @@ -159,15 +185,6 @@ typedef uint16_t unaligned_uint16_t;
> #define __rte_packed_end __attribute__((__packed__))
> #endif
>
> -/**
> - * Macro to mark a type that is not subject to type-based aliasing rules
> - */
> -#ifdef RTE_TOOLCHAIN_MSVC
> -#define __rte_may_alias
> -#else
> -#define __rte_may_alias __attribute__((__may_alias__))
> -#endif
> -
> /******* Macro to mark functions and fields scheduled for removal *****/
> #ifdef RTE_TOOLCHAIN_MSVC
> #define __rte_deprecated
This change raises a warning in checkpatch.
https://mails.dpdk.org/archives/test-report/2026-February/955237.html
IIRC, we added this check for MSVC support, making sure no
__rte_aligned() would be added in unsupported locations.
@Microsoft guys, do you have a suggestion?
--
David Marchand
