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 ESMTPS id 41C71385843A for ; Mon, 18 Oct 2021 09:00:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 41C71385843A Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-596-Q8jmUFdPOFq7IoRVpP3u7w-1; Mon, 18 Oct 2021 05:00:31 -0400 X-MC-Unique: Q8jmUFdPOFq7IoRVpP3u7w-1 Received: by mail-qk1-f197.google.com with SMTP id bj35-20020a05620a192300b0045fdc4bebcfso7137235qkb.23 for ; Mon, 18 Oct 2021 02:00:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:organization:date:message-id :user-agent:mime-version; bh=StiyGGkFowfG4uktKCWUsdalcpRel+VplbcA+7QrXGo=; b=FqW2dH3lmvf921vSp7ERr+eyTCdcAblZDbPM9HDUc7Kej3DmZTutOKez1J28O0AZgh 2KihIKwHVJmlpfdVbBDKx2eSSHVDs80VA4VtGbW/+UpCSxMfJDeWOw4QxJF5B1xAgST5 bjUNzBBEIy27Cr7SfxYMAi3x78Hnu4AGxB9HDRg2TTFGaNrR1L4cwmhFmFan+pjGeeP1 vX40xLtIAtrV+4dnGRXhE/VnPWT5HXWGk8jPnmLb6HwIBu+sTr3FwcG9en1YB6Mwu5Mo zrrUJWUHgGfRpDsxPMspO5lERlpt9fHmqlEHvwcXZFh4+lp0WMie732+TX8gU7wdXzOn +kKA== X-Gm-Message-State: AOAM530dBS6LN0rgTYv/tqdrTXYX+jRN9t7Pi28cL365e9IhsyHsty7Z +XAZfgJhPD6XIuO5szvLwzopzcFpqOHuO92HEY2r5aXPW57JnGBoWZuTKIakgU8Y8z90acYGojC VLX5KpHIfJB+K3aJp0JGWtwsNdOxv1igC5GF2i8AkPXWl9GjIuHOKgY9Kji5+/MtUruQt X-Received: by 2002:a05:620a:238:: with SMTP id u24mr20777170qkm.462.1634547630539; Mon, 18 Oct 2021 02:00:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsPvYznTCXQlh30cGC9T9PadrkmECoXUHPI62qa8NUJS5cANEjfrgLVyCJRh2CCL+74bICnQ== X-Received: by 2002:a05:620a:238:: with SMTP id u24mr20777147qkm.462.1634547630203; Mon, 18 Oct 2021 02:00:30 -0700 (PDT) Received: from localhost ([88.120.130.27]) by smtp.gmail.com with ESMTPSA id a15sm5629305qkp.17.2021.10.18.02.00.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 02:00:29 -0700 (PDT) Received: by localhost (Postfix, from userid 1000) id 24AF35802BD; Mon, 18 Oct 2021 11:00:28 +0200 (CEST) From: Dodji Seketeli To: libabigail@sourceware.org Subject: [PATCH, applied] Bug 28364 - libwiretap fails self comparison Organization: Red Hat / France X-Operating-System: Fedora 36 X-URL: http://www.redhat.com Date: Mon, 18 Oct 2021 11:00:27 +0200 Message-ID: <87o87mbtck.fsf@redhat.com> 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 Content-Type: text/plain X-Spam-Status: No, score=-6.1 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_H2, 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: Mon, 18 Oct 2021 09:00:36 -0000 Hello, In this case, thanks to all the debugging infrastructure in place, especially the canonical type debugging infrastructure, I was able to notice that there was a canonicalization error on a function type when reading the libwiretap binary as in: $ build/tools/abidw --debug-tc /usr/lib64/libwiretap.so.11.0.8 structural & canonical equality different for type: function type void (wtap*) in compare_types_during_canonicalization at: /home/dodji/git/libabigail/PR28364/src/abg-ir.cc:13575: execution should not have reached this point! Abandon (core dumped) $ When digging deeper, I noticed that, in the DWARF reader, when building a function type, we are associating a "textual representation" of the function type 'void (wtap*)' to its DIE (inside the current translation) way too early. By too early, I mean, the association was done before the function type was fully 'built'. Its parameters were not 'collected', for instance. So that means that a 'pointer to that function type' could be formed, with a wrong representation, during the time where the function type wasn't fully formed. Just moving the association to after the type was fully constructed solved the issue. This one was hard to spot! Later, this uncovered the fact that we could now have (and thus serialize) member functions of unions. And it turned out the abixml reader didn't expect those. Oops. I fixed that one as well. * src/abg-dwarf-reader.cc (build_function_type): Associate the DIE representation to the constructed type once it's fully built. * src/abg-reader.cc (build_function_type): Support member function of unions. * tests/data/Makefile.am: Add the new test input files to the source distribution. * tests/data/test-diff-pkg/wireshark/wireshark-cli-3.4.9-1.fc36.x86_64-self-check-report.txt: Add new test input file. * tests/data/test-diff-pkg/wireshark/wireshark-cli-3.4.9-1.fc36.x86_64.rpm: Likewise. * tests/data/test-diff-pkg/wireshark/wireshark-cli-debuginfo-3.4.9-1.fc36.x86_64.rpm: Likewise. * tests/test-diff-pkg.cc (in_out_specs): Add these new test input files to this test harness. * tests/data/test-read-dwarf/PR25007-sdhci.ko.abi: Adjust. Signed-off-by: Dodji Seketeli Applied to master. --- src/abg-dwarf-reader.cc | 3 ++- src/abg-reader.cc | 6 ++--- tests/data/Makefile.am | 3 +++ ...-3.4.9-1.fc36.x86_64-self-check-report.txt | 21 ++++++++++++++++++ .../wireshark-cli-3.4.9-1.fc36.x86_64.rpm | Bin 0 -> 21382553 bytes ...hark-cli-debuginfo-3.4.9-1.fc36.x86_64.rpm | Bin 0 -> 39197386 bytes .../data/test-read-dwarf/PR25007-sdhci.ko.abi | 2 +- tests/test-diff-pkg.cc | 12 ++++++++++ 8 files changed, 42 insertions(+), 5 deletions(-) create mode 100644 tests/data/test-diff-pkg/wireshark/wireshark-cli-3.4.9-1.fc36.x86_64-self-check-report.txt create mode 100644 tests/data/test-diff-pkg/wireshark/wireshark-cli-3.4.9-1.fc36.x86_64.rpm create mode 100644 tests/data/test-diff-pkg/wireshark/wireshark-cli-debuginfo-3.4.9-1.fc36.x86_64.rpm The patch is too big to attach to this email. You can browse its content at https://sourceware.org/git/?p=libabigail.git;a=commit;h=991283269ea8eb9bf9b1d1f460164c222f60e888. Cheers, -- Dodji