From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B7CD3A04A4 for ; Fri, 17 Dec 2021 16:02:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A7D9740040; Fri, 17 Dec 2021 16:02:07 +0100 (CET) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by mails.dpdk.org (Postfix) with ESMTP id BD02E40040 for ; Fri, 17 Dec 2021 16:02:05 +0100 (CET) Received: by mail-wr1-f42.google.com with SMTP id q16so4597800wrg.7 for ; Fri, 17 Dec 2021 07:02:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=XnvhOby2VVQPuvHuk44mTk3e7iE/QETx7Qj/R53jXZc=; b=QVGYgR4I3sZ9eEU+WndDCnFFQKT1sm1nk/4RJ8909SQP0H47gkok1HpHwWwD948DjL 2aUJOVv425NoCCWDh7ZJ6gLt7Wqy9qH2/Vi+7UBZlMJsr4eRDSS5wW0lz42wM0/K6jJX /GiumoS4VLK4nza8SMmpk5LjPCLbpgzX+GqMa7rr1px+B52p7AllYz4bRifgHF/qGcTg BJ7kSBl0eLy26NPwppNeAOpj/WlKyoJFY1hi1ZNYMburwjUc9WKln/E+8xtP6F1BkfTx O5a4acggMN402Nhkf26fQpeKUCZ+1P2Z1WJ1YjTraW8TXqKo41loMWuz3vdquw5klWmg GflA== X-Gm-Message-State: AOAM533OLtiAWf7khBk14+qSzMVLIlDJ2sZ/QOgfEaBofalZ4yQmsk2Q 3yo8vHmFRTYxeVCfFfdFORU= X-Google-Smtp-Source: ABdhPJwfR217zEB1GQbYUskl2tFwtiXHDZdrH7xB9Vi5wjqlfp0Qzy6GE8RFiDgQPDQFHOK/WHG/cw== X-Received: by 2002:a5d:4810:: with SMTP id l16mr22904wrq.672.1639753325432; Fri, 17 Dec 2021 07:02:05 -0800 (PST) Received: from localhost ([2a01:4b00:f41a:3600:360b:9754:2e3a:c344]) by smtp.gmail.com with ESMTPSA id f13sm2996907wri.51.2021.12.17.07.02.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 07:02:04 -0800 (PST) Message-ID: Subject: Re: [PATCH] cryptodev: fix stringop-overflow build failure with gcc 10 From: Luca Boccassi To: "Richardson, Bruce" , "christian.ehrhardt@canonical.com" , "stable@dpdk.org" Cc: "ktraynor@redhat.com" , Thomas Monjalon , "Yigit, Ferruh" Date: Fri, 17 Dec 2021 15:02:04 +0000 In-Reply-To: References: <20211217095124.3500864-1-christian.ehrhardt@canonical.com> <579800f9f68738b114417f807c3a539fd96a093b.camel@debian.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, 2021-12-17 at 12:09 +0000, Richardson, Bruce wrote: >=20 > > -----Original Message----- > > From: Luca Boccassi > > Sent: Friday, December 17, 2021 12:01 PM > > To: christian.ehrhardt@canonical.com; stable@dpdk.org > > Cc: Richardson, Bruce ; ktraynor@redhat.com= ; > > Thomas Monjalon ; Yigit, Ferruh > > > > Subject: Re: [PATCH] cryptodev: fix stringop-overflow build failure wit= h > > gcc 10 > >=20 > > On Fri, 2021-12-17 at 10:51 +0100, christian.ehrhardt@canonical.com > > wrote: > > > From: Christian Ehrhardt > > >=20 > > > 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". > > >=20 > > > But the combination of 19.11 and gcc 10.3.0 and LTO this can still > > > exposes the issue. > > >=20 > > > [ 549s] In function =E2=80=98_mm_storeu_si128=E2=80=99, > > > [ 549s] inlined from =E2=80=98rte_memcpy_generic=E2=80=99 > > > =C2=A0=C2=A0at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h= :508:2, > > > [ 549s] inlined from =E2=80=98rte_cryptodev_sym_session_set_user= _data=E2=80=99 > > > =C2=A0=C2=A0at ../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: > > > =C2=A0=C2=A0error: writing 16 bytes into a region of size 0 > > > =C2=A0=C2=A0[-Werror=3Dstringop-overflow=3D] > > > [ 549s] 727 | *__P =3D __B; > > > [ 549s] | ^ > > > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.c: > > > =C2=A0=C2=A0In function =E2=80=98rte_cryptodev_sym_session_set_user_d= ata=E2=80=99: > > > [ 549s] ../lib/librte_cryptodev/rte_cryptodev.h:984:4: note: > > > =C2=A0=C2=A0at offset 0 to object =E2=80=98sess_data=E2=80=99 with si= ze 0 declared here > > > [ 549s] 984 | } sess_data[0]; > > > [ 549s] | ^ > > >=20 > > > 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. > > >=20 > > > For affected compilers set -Wno-stringop-overflow globally for > > > the linker stage to avoid this breaking the build in any place. > > >=20 > > > Buzilla ID: 908 > > >=20 > > > [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94335 > > > [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D92955 > > > [3]: https://github.com/DPDK/dpdk/commit/b5b3ea803e47 > > >=20 > > > Signed-off-by: Christian Ehrhardt > > > --- > > > =C2=A0config/meson.build | 8 ++++++++ > > > =C2=A01 file changed, 8 insertions(+) > > >=20 > > > 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'= ) > > > =C2=A0 dpdk_extra_ldflags +=3D '-lnuma' > > > =C2=A0endif > > >=20 > > >=20 > > > +# Some false positives can trigger at LTO stage, so this warning nee= ds > > to be > > > +# disabled on the linker as well for gcc 10. > > > +# Fixed in gcc-11 and not present > > +# https://bugs.dpdk.org/show_bug.cgi?id=3D908 > > > +if cc.get_id() =3D=3D 'gcc' and cc.version().version_compare('>=3D10= .0') and > > cc.version().version_compare('<11.0') > > > + add_project_link_arguments('-Wno-stringop-overflow', language: 'c') > > > +endif > > > + > > > =C2=A0has_libfdt =3D 0 > > > =C2=A0fdt_dep =3D cc.find_library('libfdt', required: false) > > > =C2=A0if fdt_dep.found() and cc.has_header('fdt.h') > >=20 > > Sounds reasonable to me. Is it possible to detect that LTO is used, to > > further restrict when this is applied? > >=20 >=20 > Does it really matter that much? This is for backport only, so won't appl= y for main tree, meaning that all backported patches will have been already= checked with the setting enabled on the mainline. Therefore, I would look = to not bother trying to limit the impact of the flag much, and just enable = it in the most convenient manner. >=20 > /Bruce Just thinking about coverage for future backports, but it's not too important --=20 Kind regards, Luca Boccassi