[PATCH] cryptodev: fix stringop-overflow build failure with gcc 10

[Luca Boccassi]

On Fri, 2021-12-17 at 10:51 +0100, christian.ehrhardt at canonical.com
wrote:
> From: Christian Ehrhardt <christian.ehrhardt at canonical.com>
> 
> 19.11 LTS releases started to fail to build in some newer releases
> due to newer gcc-10 compilers available. Those are mostly false
> positives [1][2] and to some extend covered by the already present
> backports of "4990929c60 eal/ppc: ignore GCC 10 stringop-overflow
> warnings" and "df17bcb43b eal/x86: ignore gcc 10 stringop-overflow
> warnings".
> 
> But the combination of 19.11 and gcc 10.3.0 and LTO this can still
> exposes the issue.
> 
> [  549s] In function ‘_mm_storeu_si128’,
> [  549s]     inlined from ‘rte_memcpy_generic’
>   at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:508:2,
> [  549s]     inlined from ‘rte_cryptodev_sym_session_set_user_data’
>   at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:882:10:
> [  549s] /usr/lib/gcc/x86_64-linux-gnu/10/include/emmintrin.h:727:8:
>   error: writing 16 bytes into a region of size 0
>   [-Werror=stringop-overflow=]
> [  549s]   727 |   *__P = __B;
> [  549s]       |        ^
> [  549s] ../lib/librte_cryptodev/rte_cryptodev.c:
>   In function ‘rte_cryptodev_sym_session_set_user_data’:
> [  549s] ../lib/librte_cryptodev/rte_cryptodev.h:984:4: note:
>   at offset 0 to object ‘sess_data’ with size 0 declared here
> [  549s]   984 |  } sess_data[0];
> [  549s]       |    ^
> 
> The problem is that in this combination only at link time (LTO)
> the compiler will (false-)detect the problematic size of the target
> structure and break. To make things worse [3] fixed this problem
> for the same issue at actual build time, but the pragma has no
> effect at link time nor are any werror settings passed to the
> linker.
> 
> For affected compilers set -Wno-stringop-overflow globally for
> the linker stage to avoid this breaking the build in any place.
> 
> Buzilla ID: 908
> 
> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
> [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
> [3]: https://github.com/DPDK/dpdk/commit/b5b3ea803e47
> 
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt at canonical.com>
> ---
>  config/meson.build | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/config/meson.build b/config/meson.build
> index 4007b8f37c..25dec320ba 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -143,6 +143,14 @@ if numa_dep.found() and cc.has_header('numaif.h')
>  	dpdk_extra_ldflags += '-lnuma'
>  endif
>  
> 
> +# Some false positives can trigger at LTO stage, so this warning needs to be
> +# disabled on the linker as well for gcc 10.
> +# Fixed in gcc-11 and not present <gcc-10
> +# https://bugs.dpdk.org/show_bug.cgi?id=908
> +if cc.get_id() == 'gcc' and cc.version().version_compare('>=10.0') and cc.version().version_compare('<11.0')
> +	add_project_link_arguments('-Wno-stringop-overflow', language: 'c')
> +endif
> +
>  has_libfdt = 0
>  fdt_dep = cc.find_library('libfdt', required: false)
>  if fdt_dep.found() and cc.has_header('fdt.h')

Sounds reasonable to me. Is it possible to detect that LTO is used, to
further restrict when this is applied?

-- 
Kind regards,
Luca Boccassi