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 70A89A034F for ; Mon, 7 Jun 2021 10:34:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3E0654067E; Mon, 7 Jun 2021 10:34:16 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 2B9F640147 for ; Mon, 7 Jun 2021 10:34:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623054853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nPRiVoIaks126WO+WObbCw9CaNhq9XqeyLoYwZDf1gM=; b=LQil1fqMQOJh4rZp9TJ4jOgpcX2nouiqg1qUxUGhO/H6PSw+M9mL/nYvHwWC21vatO1pQ5 mxQMJYF0/tOr/gjk1Q4+w/Ma5Ooo4hp6PUmwFhGWjOaNprk0kOxj84ro8YR5T3KzOKnQ25 ZSBRHl51vvsX1pbUmXGH5SiHNdL3b0s= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-194-izlnCevCNQu5BV7lU2xaeQ-1; Mon, 07 Jun 2021 04:34:10 -0400 X-MC-Unique: izlnCevCNQu5BV7lU2xaeQ-1 Received: by mail-vs1-f71.google.com with SMTP id m14-20020a67fe4e0000b0290255df7450beso6372083vsr.8 for ; Mon, 07 Jun 2021 01:34:10 -0700 (PDT) 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=nPRiVoIaks126WO+WObbCw9CaNhq9XqeyLoYwZDf1gM=; b=rthYFSxOBj2LR+nnt2Ck2a9UxRUV52/8NV1+xXexKk01amDA7eE7rl3uM1Z8VfYTjM AFjwgzMH678i4Y0YB1QWT32VYBrs3Yi7Ckr2MyfSBu1XPx7OE5O4QeWGz13QGLlDxK/d 9YBouhBC7yEv769lyXILWnolwqMTyGJ5qAKrhll6cnRMagxTcbBoghCGmh7kN4xVu6f4 Rwf+0VSDmiM+pjK9DcaPpqEEt16FpTixiX/zbnJhQKlEjM+d5uwT0GjIR5C88jZxnAEI tQoFwZXGbzWyQaBgnx9zQmKby4wikTk0Tx/OX3d3FdoWt746+zpe5EKYh98AUryNkhna 5XNQ== X-Gm-Message-State: AOAM532NcTH9pZO18y0bB3WxQ9rGufn5Qt1cN0BIerapW6HSZBULbkG/ iCjzbDpLtQ5F9TwiNZn0haeltTMN7AUs6p0UZT5tenhlzWME6iMNXUVMlS851pQjfUemD67j38q Po8izawraGsBL+tInzw== X-Received: by 2002:a67:f952:: with SMTP id u18mr88198vsq.5.1623054850411; Mon, 07 Jun 2021 01:34:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaLoO848fS7WMXHdp+PyBzzo8Pyv0rS0Nclu+I1IqLQCl5I+5gm3bwxmxIEpsO3ThfjNQAqXTZw7zb9dynuNE= X-Received: by 2002:a67:f952:: with SMTP id u18mr88188vsq.5.1623054850185; Mon, 07 Jun 2021 01:34:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Marchand Date: Mon, 7 Jun 2021 10:33:59 +0200 Message-ID: To: Lincoln Lavoie Cc: dpdklab , ci@dpdk.org, Aaron Conole , Thomas Monjalon , Ray Kinsella , Dodji Seketeli Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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" Trying to do a post mortem. On Fri, Jun 4, 2021 at 3:53 PM Lincoln Lavoie wrote: > The ABI references for all systems were updated this week to the 21.05 re= lease code. The two failures look like places where the interfaces didn't = actually change. We do see the failures across multiple patches, which migh= t 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 Adde= d 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, uint= 64_t*, void**)*' changed: > in pointed to type 'function type int (void*, rte_mbuf**, typ= edef 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 pack= et_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_ty= pe; 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_type= ;};}; uint8_t inner_l4_type;}' changed: > type size hasn't changed > 3 data member changes: > 'uint8_t inner_l4_type' offset changed from= 0 to 24 (in bits) (by +24 bits) > 'uint8_t l4_type' offset changed from 0 to = 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? --=20 David Marchand