From patchwork Mon Feb 7 11:11:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dodji Seketeli X-Patchwork-Id: 50853 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4CA5A3858418 for ; Mon, 7 Feb 2022 11:11:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4CA5A3858418 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1644232294; bh=JRSTyxGwolU7Sw1s/6M7/M6bK/s7fLlRSVeZN0+3Wuo=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Help:List-Subscribe:From:Reply-To:Cc:From; b=frGKIV0Gptypkthrq+kXimdL0YmFcWSNi7F6zxjoEJJ6BtxUj4R4w423yul98y7R2 /o4mJHTo8Y6LF2SGEqWgrwaX2jumvr+uLVp0ryVVMwrL3ZEMfOg8UTdDuSZ/nOnaSc opMFWjq561Kwh2kLhLSIKRdYRX2uVRz4K7vmEBTs= X-Original-To: libabigail@sourceware.org Delivered-To: libabigail@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C72693858D20 for ; Mon, 7 Feb 2022 11:11:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C72693858D20 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-394-hQMxFcG4O6GoHWljY_N95Q-1; Mon, 07 Feb 2022 06:11:26 -0500 X-MC-Unique: hQMxFcG4O6GoHWljY_N95Q-1 Received: by mail-qv1-f72.google.com with SMTP id l3-20020a0ce503000000b0042c0129c766so801709qvm.20 for ; Mon, 07 Feb 2022 03:11:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=JRSTyxGwolU7Sw1s/6M7/M6bK/s7fLlRSVeZN0+3Wuo=; b=q8Ci650Ob7//K0NOVvu+7uiY+kMiNdj91IdX4+j+RZrHkf2kd5npT2sy6C0oIO59eU xD3MJ6EB9QRgPwaY7SWLA1a10tX6wgS3Q2wYs4HAkbwERoIPNdPZK1Dds+bd5T15KZ47 QS1hZzJa6k4+V5nMKc6AEYx8OCKuh7O9OzqiZ5lVymu1h6OeaFVtWxppvol+5Itfv8f+ h9MLIdofGaNi66JyRZx1VuaEpUBC1nWnbqpJUGTzNLACkk1bZvpXIFOIBrBSxFzcPNrx G1Q45T52/6uIjQzCVEqW14FwH5jCGXilMoa67ALMG/0U8JsX3IX1edkApF4KY9Vkmg6Y 2GXQ== X-Gm-Message-State: AOAM532ZB4PF24N3/bmGHBC+xf7PCXxqFJe2aIrw9Ptyb9dv2s5aKVa7 eRXbyLVFGO++2096TTkYUFE/ctjwnpB/D+kSx9OLrCMgBuMqiV9FHGYn8miFNigSJObmjPKmvHa EY78mNGWD/kx+6G7KN+JW X-Received: by 2002:a37:a107:: with SMTP id k7mr5917478qke.333.1644232286014; Mon, 07 Feb 2022 03:11:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJyuh+sc9mhtATFPk2/faFFCkmDSHniHHL4MoigOw3sp62qtrLpWMv6SIO2fvFsam/RBhg8QsQ== X-Received: by 2002:a37:a107:: with SMTP id k7mr5917471qke.333.1644232285797; Mon, 07 Feb 2022 03:11:25 -0800 (PST) Received: from localhost ([88.120.130.27]) by smtp.gmail.com with ESMTPSA id g20sm5534629qko.27.2022.02.07.03.11.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Feb 2022 03:11:25 -0800 (PST) Received: by localhost (Postfix, from userid 1000) id 101F15802BD; Mon, 7 Feb 2022 12:11:24 +0100 (CET) To: libabigail@sourceware.org Subject: [PATCH 2/2] Bug 26646 - unexpected declaration-only types References: <87v8xrlyyd.fsf@redhat.com> X-Operating-System: Fedora 36 Date: Mon, 07 Feb 2022 12:11:23 +0100 In-Reply-To: <87v8xrlyyd.fsf@redhat.com> (Dodji Seketeli via Libabigail's message of "Mon, 07 Feb 2022 12:04:42 +0100") Message-ID: <87mtj3lyn8.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_FILL_THIS_FORM_SHORT, T_SCC_BODY_TEXT_LINE 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-Patchwork-Original-From: Dodji Seketeli via Libabigail From: Dodji Seketeli Reply-To: Dodji Seketeli Cc: maennich@google.com Errors-To: libabigail-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libabigail" In a version of the kernel binary referred to in this problem report, the parameter 'skb' of the udp4_hwcsum function, which is of type "pointer to struct sk_buff", indirectly refers to a pointer to a declaration-only struct ip_mc_list. In another version of that kernel binary, the same parameter skb of the udp4_hwcsum function is still of type "pointer to struct sk_buff", but in that case, the sk_buff indirectly refers to a pointer to a fully defined struct ip_mc_list. The first kernel only contains a decl-only struct ip_mc_list whereas the second one contains a fully defined struct ip_mc_list. This problem comes from the fact that in add_or_update_class_type, we "reuse" the "struct sk_buff" that we've already seen in the same binary, if any. Depending on the order in which types are defined in the debug information, if the DIE for struct sk_buff that refers to a decl-only struct ip_mc_list has already been "seen" by the DWARF-reader, then add_or_update_class_type re-uses the IR of that DIE that's been constructed already; otherwise, the IR for the struct sk_buff represented by the current DIE is constructed. This patch fixes the problem by always constructing an IR for the DIE that is being seen, in add_or_update_class_type. * src/abg-dwarf-reader.cc (add_or_update_class_type): Do not reuse the IR for a DIE with the same textual representation as the one we are seeing now. * tests/data/test-annotate/test21-pr19092.so.abi: Adjust. * tests/data/test-read-dwarf/test21-pr19092.so.abi: Likewise. Signed-off-by: Dodji Seketeli --- src/abg-dwarf-reader.cc | 13 ------------- tests/data/test-annotate/test21-pr19092.so.abi | 2 +- tests/data/test-read-dwarf/test21-pr19092.so.abi | 2 +- 3 files changed, 2 insertions(+), 15 deletions(-) diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc index d8545b4c..53b5845d 100644 --- a/src/abg-dwarf-reader.cc +++ b/src/abg-dwarf-reader.cc @@ -12160,19 +12160,6 @@ add_or_update_class_type(read_context& ctxt, } } - if (!ctxt.die_is_in_cplus_plus(die)) - // In c++, a given class might be put together "piecewise". That - // is, in a translation unit, some data members of that class - // might be defined; then in another later, some member types - // might be defined. So we can't just re-use a class "verbatim" - // just because we've seen previously. So in c++, re-using the - // class is a much clever process. In the other languages however - // (like in C) we can re-use a class definition verbatim. - if (class_decl_sptr class_type = - is_class_type(ctxt.lookup_type_from_die(die))) - if (!class_type->get_is_declaration_only()) - return class_type; - string name, linkage_name; location loc; die_loc_and_name(ctxt, die, loc, name, linkage_name); diff --git a/tests/data/test-annotate/test21-pr19092.so.abi b/tests/data/test-annotate/test21-pr19092.so.abi index e009a191..bb87fc54 100644 --- a/tests/data/test-annotate/test21-pr19092.so.abi +++ b/tests/data/test-annotate/test21-pr19092.so.abi @@ -4395,7 +4395,7 @@ - + diff --git a/tests/data/test-read-dwarf/test21-pr19092.so.abi b/tests/data/test-read-dwarf/test21-pr19092.so.abi index c10916fa..90ecd590 100644 --- a/tests/data/test-read-dwarf/test21-pr19092.so.abi +++ b/tests/data/test-read-dwarf/test21-pr19092.so.abi @@ -2915,7 +2915,7 @@ - +