The common tests that expected unaligned to really have no guaranteed alignment would fail with UBSAN. The root cause was the definition of unaligned still implied alignment on x86.
Signed-off-by: Stephen Hemminger <[email protected]> --- doc/guides/rel_notes/release_26_11.rst | 6 ++++++ lib/eal/include/rte_common.h | 13 ++++++++----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/doc/guides/rel_notes/release_26_11.rst b/doc/guides/rel_notes/release_26_11.rst index 4cadfc1918..4b219cbc97 100644 --- a/doc/guides/rel_notes/release_26_11.rst +++ b/doc/guides/rel_notes/release_26_11.rst @@ -109,6 +109,12 @@ API Changes compile with an integer argument, but this is deprecated usage: existing code should use ``RTE_ALIGN``, ``RTE_ALIGN_CEIL`` or ``RTE_ALIGN_FLOOR`` instead. +* **eal: Unaligned integer types are now really unaligned.** + + ``unaligned_uint16_t``, ``unaligned_uint32_t`` and ``unaligned_uint64_t`` + are now declared with an alignment of 1 on all architectures. + The compiler may generate narrower loads and stores than before. + ABI Changes ----------- diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h index ed037be399..bb7dfb8ba5 100644 --- a/lib/eal/include/rte_common.h +++ b/lib/eal/include/rte_common.h @@ -149,14 +149,17 @@ extern "C" { #define __rte_aligned(a) __attribute__((__aligned__(a))) #endif -#ifdef RTE_ARCH_STRICT_ALIGN +/** + * Integer types with no alignment requirement. + */ +#ifdef RTE_TOOLCHAIN_MSVC +typedef __unaligned uint64_t unaligned_uint64_t; +typedef __unaligned uint32_t unaligned_uint32_t; +typedef __unaligned uint16_t unaligned_uint16_t; +#else 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); -#else -typedef uint64_t unaligned_uint64_t; -typedef uint32_t unaligned_uint32_t; -typedef uint16_t unaligned_uint16_t; #endif /** -- 2.53.0
