From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id F10B2385C40F for ; Sat, 10 Jul 2021 19:16:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F10B2385C40F Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-66-Od2w3GMkPlyYz5ZCrwvy6A-1; Sat, 10 Jul 2021 15:16:05 -0400 X-MC-Unique: Od2w3GMkPlyYz5ZCrwvy6A-1 Received: by mail-vs1-f72.google.com with SMTP id m186-20020a6726c30000b029025c048b9aefso3398030vsm.9 for ; Sat, 10 Jul 2021 12:16:05 -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; bh=1bVxt8TMHt5TRHJsjHmop6mhmgRr2lskCiBiI9cR1qE=; b=KTELUqk7pmgUnypG30jA/8TCNCvCBwgjddKfeovlYSEYbBmF7Ad+8rBAxdzuWBvSiF i6m+hpAr1RWDzu31BBL9UVQR1rku+xuAFSoileNZBxG2qE3AkvfjkFKPKYHbHNkXBUDo CWGCeT/xUMibHZcq15qz2NJ9JC/i2ZHw+s7SRciIDrJVB5lIfbSg9jnop2GjUwIdTWte 3CH4CYiueNQoiQgrq5DKWTb8d1ryxGifE2FPYal0jNiRv0ucQrqpid0Aa7FJi+GrA9VA sXmhcZS/RQN8wa/Q4yS5oOefoAawv4ZImPNOV4yZM3bVfW7mmoaDKifdIw0WAQ3FniQK CTRA== X-Gm-Message-State: AOAM530xNLH9SbdQWoPRlKuSC3DCX03BtnIhsgmELfF0320lJAi7pYDO e+6PEamhaBdQ1DwU3bWUs2QY73zTTXQZVvkpbBDWi6lAdh2XEeZHA1CKZX/9B895RyEtnRbAjjq hS6xncgvglh4OZOzakdMQxi4dg2RjCytAlMH7 X-Received: by 2002:a67:f3d1:: with SMTP id j17mr35606855vsn.18.1625944565288; Sat, 10 Jul 2021 12:16:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyploF65IK8NVsKjXtVHFv552jrROhG8ZiZTuVSPtRojl0qErbJjefVlWyCBRBWofUdt99jgUHiV8RfyWMO+5s= X-Received: by 2002:a67:f3d1:: with SMTP id j17mr35606844vsn.18.1625944565062; Sat, 10 Jul 2021 12:16:05 -0700 (PDT) MIME-Version: 1.0 References: <20210709231649.2969609-1-gprocida@google.com> <20210709231649.2969609-2-gprocida@google.com> In-Reply-To: From: David Marchand Date: Sat, 10 Jul 2021 21:15:53 +0200 Message-ID: Subject: Re: [PATCH 1/1] DWARF reader: fix bitfield offset calculations To: Giuliano Procida Cc: libabigail@sourceware.org, Dodji Seketeli , kernel-team@android.com, maennich@google.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 19:16:14 -0000 On Sat, Jul 10, 2021 at 6:52 PM Giuliano Procida wrote: > > > > But now, I face an issue trying to waive this. > > The addition of the "dev_configured" field in this bitfield is right > > after a 1 bit wide "lro" field and before a "rx_queue_state" field. > > https://git.dpdk.org/dpdk/tree/lib/ethdev/rte_ethdev_core.h?id=f0b97fc4fe4cd16dd492cf30ece4296451e10e10#n165 > > > > The rule below does not work: > > [suppress_type] > > name = rte_eth_dev_data > > has_data_member_inserted_between = {offset_after(lro), > > offset_of(rx_queue_state)} > > > > While on the other hand, this one works: > > [suppress_type] > > name = rte_eth_dev_data > > has_data_member_inserted_between = {34005, offset_of(rx_queue_state)} > > > > Not sure what the issue is, but supposing the offsets are now correct, > > then my bet is on the "lro" field size (here, 1 bit). > > > > I'd open a separate bug for that. Yep, I hesitated at first, but now I think we need one, see below. > > > > > Back to my reproducer, that I updated: > > > > struct bigstruct { > > char name[128]; > > uint8_t bitfield0:1 > > #ifndef BEFORE > > ,bitfield1:1 > > #endif > > ; > > uint8_t other; > > }; > > > > I wrote a suppression rule: > > [suppress_type] > > name = bigstruct > > has_data_member_inserted_between = {offset_after(bitfield0), > > offset_of(other)} > > > > And then I tried to debug, but I am lost in libabigail internals. > > I attached a gdb to catch all get_size_in_bits() calls, I see either > > 1024 (sizeof name), 8 (sizeof other?), 0 (this is suspicious) or 64 > > (?). > > > > I would advise the following: separate ABI extraction (abidw) from ABI > comparison (abidiff), if you haven't already. That's what we do in dpdk. Just, for testing here, I only used abidiff with object files. > > You can at least carefully check the XML before comparing XML files. Yeah, good idea, and so, looking at xml: ^^^^^^^^^ My two 1bit fields are marked with type-id-8 which I understand points at uint8_t. I'll open a bz. -- David Marchand