From patchwork Mon Feb 7 11:09:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dodji Seketeli X-Patchwork-Id: 50852 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 67042385841E for ; Mon, 7 Feb 2022 11:09:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67042385841E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1644232196; bh=laypqWFuo0LKZXzI97vmE0X8sFEw0oQZeq88A7kPdLQ=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Help:List-Subscribe:From:Reply-To:Cc:From; b=kUtPMpHMldW/4JaonRQ0tU64Rh9nlmy8usCZdmm8K8nwD8WwqeOxmHxHB1bFkMZ6m Ts/bnhU5EOMS9k7iCqCsCC1hj+464mFDuAwRmXqJBCEkDJUoBfFRpVDBpft83/ONy4 RnPG114Vpsw3/MrDBZrS3dFCjBb0kW5zujpGa70Y= 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.129.124]) by sourceware.org (Postfix) with ESMTPS id 04EEE3858D20 for ; Mon, 7 Feb 2022 11:09:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 04EEE3858D20 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-465-WdnuPCKuMyO1gP_fDfklXw-1; Mon, 07 Feb 2022 06:09:48 -0500 X-MC-Unique: WdnuPCKuMyO1gP_fDfklXw-1 Received: by mail-qk1-f200.google.com with SMTP id p23-20020a05620a15f700b00506d8ec3749so8351946qkm.4 for ; Mon, 07 Feb 2022 03:09:48 -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=laypqWFuo0LKZXzI97vmE0X8sFEw0oQZeq88A7kPdLQ=; b=UdtcZeJ7+/lQKFYj4hLvka36k2VILzyhkKdFjBk0B/LPnzH1SJzxDyOQQpoESELuUu NU0tloK5XOUHl2jSj2IkbtLjVd69mqDjEAV/gUDPsT+1jP3jFgVodcOi2qQn3+oe7CfR ZDoOWhK36WiDW7K8lg5g6HvAnHNEZAHmS8t1M9UHGwM6ZTX/6pDIpISGc2i614ariGYT sJrnHIan6g5GJo7AJz2ODApErMXfk81Y3XBmmxlyFjg53idv7Kr90yCQJnyEYKzYTw8U yRIonYpb84zKwdkEbqrsWmFu8Zu4reIeYhB+Zb221yY0+k5RoUwsB7HalbDu3/EFq/mf t8kw== X-Gm-Message-State: AOAM532Lx4WRBHlXuW0RjdGujDMOPnEjNBF018+HNIroF8aV2YCrsJwE 7LBPQSC2zWrmvDYEL/BOCeCHpN2/35h0EbNSybDyiH0oxR0S8e/ekI4huwqW4IAvLZU/JgB/iGD IzCDk0VP2DWoAmDUDhYPo X-Received: by 2002:a05:620a:1090:: with SMTP id g16mr5850866qkk.398.1644232187791; Mon, 07 Feb 2022 03:09:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJzxPrw3VoT1/YjyDkDvwXKKMfVYHrGdywNGuPmsKxzyDrD2tAktPYTTModYTAv/aJHlmKv5sA== X-Received: by 2002:a05:620a:1090:: with SMTP id g16mr5850855qkk.398.1644232187605; Mon, 07 Feb 2022 03:09:47 -0800 (PST) Received: from localhost ([88.120.130.27]) by smtp.gmail.com with ESMTPSA id h12sm5178949qkp.129.2022.02.07.03.09.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Feb 2022 03:09:47 -0800 (PST) Received: by localhost (Postfix, from userid 1000) id B72585802B4; Mon, 7 Feb 2022 12:09:45 +0100 (CET) To: libabigail@sourceware.org Subject: [PATCH 1/2] symtab-reader: Remove an over-agressive assertion References: <87v8xrlyyd.fsf@redhat.com> X-Operating-System: Fedora 36 Date: Mon, 07 Feb 2022 12:09:45 +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: <87r18flypy.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_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 symtab::load, the symtab reader walks the symbol table and records each relation "symbol <-> address". So, the relation "foo <-> address-of-foo" is going to be recorded. The relation "foo.cfi <-> address-of-foo.cfi" is going to be recorded as well. But then, because the symbol foo.cfi has a special meaning, in the realm of "control flow integrity", the relation "foo.cfi <-> address-of-foo.cfi" (as well as all the *.cfi <-> address-of*.cfi relations) is going to be recorded (again but) in a particular way by calling symtab::add_alternative_address_lookups. The problem is that in, symtab::add_alternative_address_lookups there is an assert that (wrongly) assumes that the relation foo.cfi <-> address-of-foo.cfi is being seen for the first time. This is wrong because the loop in symtab::load that records all the "symbol <-> address" relations has seen and recorded this foo.cfi <-> address-of-foo.cfi relation once already. This patch removes that assert so that the kernel referred to in the bug report of PR26646, as mentioned in https://sourceware.org/bugzilla/show_bug.cgi?id=26646#c5, can be processed by abidw without crashing. * src/abg-symtab-reader.cc (symtab::add_alternative_address_lookups): Remove over-aggressive assert. Signed-off-by: Dodji Seketeli Reviewed-by: Giuliano Procida --- src/abg-symtab-reader.cc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/abg-symtab-reader.cc b/src/abg-symtab-reader.cc index 78dec36d..b42ce87d 100644 --- a/src/abg-symtab-reader.cc +++ b/src/abg-symtab-reader.cc @@ -651,9 +651,7 @@ symtab::add_alternative_address_lookups(Elf* elf_handle) symbol_sptr); } - const auto result = - addr_symbol_map_.emplace(symbol_value, symbol_sptr); - ABG_ASSERT(result.second); + addr_symbol_map_.emplace(symbol_value, symbol_sptr); } } } 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 @@ - +