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 CD5B8A0C47 for ; Wed, 9 Jun 2021 17:07:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A22674069B; Wed, 9 Jun 2021 17:07:43 +0200 (CEST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mails.dpdk.org (Postfix) with ESMTP id 42A144003C for ; Wed, 9 Jun 2021 17:07:43 +0200 (CEST) Received: by mail-il1-f169.google.com with SMTP id b9so26753717ilr.2 for ; Wed, 09 Jun 2021 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Guh0GggqO1UmhkAeHAsQraPJHtIhjPFd+qF9l4UC/B4=; b=CA5p14Ju8jQgqJypfTIatCqccFRjWwY3iTULlQstIkCAPdCfcrCI7SmnGZy/fhp8bv bKBM76UwnFHeqsCo+4uCkPCDqaYE7ScRblg6YHYmi06wWc5kGfeVNR/Rced9PF1qIC8p BgfER1ymcTiIygq005ggU3qMdtVWAdFlyA3IM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Guh0GggqO1UmhkAeHAsQraPJHtIhjPFd+qF9l4UC/B4=; b=GSM4W1l5YfgxmkPATLPZM3k4tLcIXswYU5reB88NPUKG2NcIJNWV61cMuJeJjRxqUO hk9DwXQgTlM9zu/NU1oanFe0lKzByJfg0X1kUpw6EYyGXdfhz34EPRdsdgvD4VmCT0FO 9Qxla0lklQG5bNFeb0XGrp0Nz/N0JF1af+cYjEuMPpbj3255PbquZi34xyTaiIESXUHt SlkoKV5ACoS+bCNDCJZrJClZxqub15qRYtDb/xJdPCmEa9BYJbQcoQee7ok0MqLqdn5R 1G1hqmy7LdbElSTSYciXXhK8Gvck737Bv/pSdRzoWyv5nnb8xYMtr+Rb0952Q13jSp22 O3Bw== X-Gm-Message-State: AOAM531PotLK8XpYeWNteehqElTcZMeocuvhFsoiVFk8VyHKInovfTnv 5N5S0bBiJLooc6AyFHnVJIHH46FgBT/juYM/9l1Jog== X-Google-Smtp-Source: ABdhPJwy85Hiocqo9liCT9VQ9A+np9JlMFM2+i4sR2Uad4lZnGnyP82Va3XHwv2E5cXtkGPKiVZzQtzYnDlouvzg+H8= X-Received: by 2002:a05:6e02:b:: with SMTP id h11mr186139ilr.188.1623251262178; Wed, 09 Jun 2021 08:07:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Lo Date: Wed, 9 Jun 2021 11:07:07 -0400 Message-ID: To: David Marchand Cc: Lincoln Lavoie , dpdklab , ci@dpdk.org, Aaron Conole , Thomas Monjalon , Ray Kinsella , Dodji Seketeli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-ci] [dpdklab] ABI test failing for openSUSE and Arch Linux X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" Hi David, For the Arch container, the gcc version did update to 11.1 which contributed to this error. The OpenSUSE container also underwent a similar update process where various packages related to the toolchain were updated. However, it appears that OpenSUSE remained on gcc version 7.5.0. This is, in part, also caused by the fact that we generate the ABI references once and store them. This is simply to reduce the amount of time per ABI test. To streamline this entire process, we are working on a job or pipeline to automate refreshing all of the images and recreate the ABI references. Thanks, Brandon On Mon, Jun 7, 2021 at 4:34 AM David Marchand w= rote: > > Trying to do a post mortem. > > > On Fri, Jun 4, 2021 at 3:53 PM Lincoln Lavoie wrot= e: > > The ABI references for all systems were updated this week to the 21.05 = release code. The two failures look like places where the interfaces didn'= t actually change. We do see the failures across multiple patches, which mi= ght imply something got merged that caused these changes / failures. > > > > -----------------------------------------------------------------------= ---------------------- > > OpenSUSE > > 2 Removed function symbols not referenced by debug info: > > > > [D] _fini > > [D] _init > > This one, I am not sure what was wrong. > This is not a symbol from DPDK itself. > This comes from a libc / toolchain and/or linker change. > > > > > > -----------------------------------------------------------------------= ---------------------- > > Arch Linux (one example from the output) > > > > Functions changes summary: 0 Removed, 0 Changed, 0 Added function > > Variables changes summary: 0 Removed, 1 Changed (13 filtered out), 0 Ad= ded variables > > > > 1 Changed variable: > > > > [C] 'rte_table_ops rte_table_acl_ops' was changed at rte_table_acl.h:= 60:1: > > type of variable changed: > > type size hasn't changed > > 1 data member change: > > type of 'rte_table_op_lookup f_lookup' changed: > > underlying type 'int (void*, rte_mbuf**, typedef uint64_t, ui= nt64_t*, void**)*' changed: > > in pointed to type 'function type int (void*, rte_mbuf**, t= ypedef uint64_t, uint64_t*, void**)': > > parameter 2 of type 'rte_mbuf**' has sub-type changes: > > in pointed to type 'rte_mbuf*': > > in pointed to type 'struct rte_mbuf' at rte_mbuf_core= .h:484:1: > > type size hasn't changed > > 1 data member changes (1 filtered): > > type of 'anonymous data member union {uint32_t pa= cket_type; struct {uint8_t l2_type; uint8_t l3_type; uint8_t l4_type; uint8= _t tun_type; union {uint8_t inner_esp_next_proto; struct {uint8_t inner_l2_= type; uint8_t inner_l3_type;};}; uint8_t inner_l4_type;};}' changed: > > type size hasn't changed > > 1 data member change: > > type of 'anonymous data member struct {uint8_= t l2_type; uint8_t l3_type; uint8_t l4_type; uint8_t tun_type; union {uint8= _t inner_esp_next_proto; struct {uint8_t inner_l2_type; uint8_t inner_l3_ty= pe;};}; uint8_t inner_l4_type;}' changed: > > type size hasn't changed > > 3 data member changes: > > 'uint8_t inner_l4_type' offset changed fr= om 0 to 24 (in bits) (by +24 bits) > > 'uint8_t l4_type' offset changed from 0 t= o 8 (in bits) (by +8 bits) > > 'uint8_t tun_type' offset changed from 4 = to 12 (in bits) (by +8 bits) > > For this one, this is probably due to > https://sourceware.org/bugzilla/show_bug.cgi?id=3D26684 > > I had a discussion with Dodji (libabigail maintainer). > > Going from dwarf 4 to dwarf 5 is something that is decided at gcc / > binutils level. > > Arch Linux recently adopted gcc 11. > https://archlinux.org/packages/core/x86_64/gcc/ > > If we compare gcc 10 and gcc 11: > - https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Debugging-Options.html > "Produce debugging information in DWARF format (if that is supported). > The value of version may be either 2, 3, 4 or 5; the default version > for most targets is 4. DWARF Version 5 is only experimental. " > - https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Debugging-Options.html > "Produce debugging information in DWARF format (if that is supported). > The value of version may be either 2, 3, 4 or 5; the default version > for most targets is 5 (with the exception of VxWorks, TPF and > Darwin/Mac OS X, which default to version 2, and AIX, which defaults > to version 4)." > > So the reason, for the issue reported above, could be that the > reference had been generated before upgrading gcc to 11. > > > I have some trouble finding the actual date for the Arch Linux switch > to gcc 11 (maybe 2021/05/17). > Are you able to correlate this with the ABI reference previous generation= ? > > > -- > David Marchand > --=20 Brandon Lo UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 blo@iol.unh.edu www.iol.unh.edu