From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) by sourceware.org (Postfix) with ESMTPS id 9B95A3858D3C for ; Thu, 14 Apr 2022 09:14:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B95A3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodj@seketeli.org) by mail.gandi.net (Postfix) with ESMTPSA id F0D65FF805; Thu, 14 Apr 2022 09:14:46 +0000 (UTC) Received: by localhost (Postfix, from userid 1001) id 2E4EB1A08DD; Thu, 14 Apr 2022 11:14:46 +0200 (CEST) From: Dodji Seketeli To: Ben Woodard Cc: gprocida@google.com, libabigail@sourceware.org Subject: Re: 'src/abg-dwarf-reader.cc:compare_dies_string_attribute_value' optimization Organization: Me, myself and I References: <87wnijv616.fsf@dirichlet.schwinge.homeip.net> <87r18oynpn.fsf@euler.schwinge.homeip.net> <877d7vhcmv.fsf@seketeli.org> <8735iigtu1.fsf@seketeli.org> <04665D9C-C7CB-419C-9DBB-C68D03713D77@redhat.com> X-Operating-System: Red Hat Enterprise Linux Server 7.9 X-URL: http://www.seketeli.net/~dodji Date: Thu, 14 Apr 2022 11:14:46 +0200 In-Reply-To: <04665D9C-C7CB-419C-9DBB-C68D03713D77@redhat.com> (Ben Woodard's message of "Tue, 12 Apr 2022 19:19:31 -0700") Message-ID: <86sfqg10xl.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, 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-List-Received-Date: Thu, 14 Apr 2022 09:14:52 -0000 Hey Ben! Man, thanks a LOT for doing this. Please see my comments below. Ben Woodard a =C3=A9crit: > So I ran my standard test on this branch as of 3d277a9cc05873cf4aeb97273d= 585e0b07af917d > > 37 Consistency mismatches > /lib64/libabigail.so.0.0.0 from libabigail-2.0-2.fc36.x86_64 > /lib64/libadwaitaqtpriv.so.1.4.1 from libadwaita-qt5-1.4.1-3.fc36.x86= _64 > /lib64/libaspell.so.15.3.1 from aspell-0.60.8-9.fc36.x86_64 > /lib64/libboost_log.so.1.76.0 from boost-log-1.76.0-9.fc36.x86_64 > /lib64/libclucene-core.so.2.3.3.4 from clucene-core-2.3.3.4-42.201308= 12.e8e3d20git.fc36.x86_64 > /lib64/libdap.so.27.0.5 from libdap-3.20.9-2.fc36.x86_64 > /lib64/libdcerpc-samr.so.0.0.1 from samba-libs-4.16.0-6.fc36.x86_64 > /lib64/libdjvulibre.so.21.7.0 from djvulibre-libs-3.5.28-2.fc36.x86_64 > /lib64/dovecot/libdovecot-storage.so.0.0.0 from dovecot-2.3.18-1.fc36= .x86_64 > /lib64/libexiv2.so.0.27.5 from exiv2-libs-0.27.5-2.fc36.x86_64 > /lib64/libgdal.so.30.0.2 from gdal-libs-3.4.2-1.fc36.x86_64 > /lib64/libgeos.so.3.10.2 from geos-3.10.2-4.fc36.x86_64 > /lib64/libglibmm-2.4.so.1.3.0 from glibmm24-2.66.2-2.fc36.x86_64 > /lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/libgmpopenh26= 4.so.2.1.1 from mozilla-openh264-2.1.1-3.fc36.x86_64 > /lib64/libhdf5_cpp.so.200.1.0 from hdf5-1.12.1-5.fc36.x86_64 > /lib64/libicui18n.so.67.1 from libicu67-67.1-2.fc35.x86_64 > /lib64/libicui18n.so.69.1 from libicu-69.1-5.fc36.x86_64 > /lib64/libicuuc.so.67.1 from libicu67-67.1-2.fc35.x86_64 > /lib64/libicuuc.so.69.1 from libicu-69.1-5.fc36.x86_64 > /lib64/dyninst/libinstructionAPI.so.12.0.1 from dyninst-12.0.1-3.fc36= .x86_64 > /lib64/libjavascriptcoregtk-4.0.so.18.20.4 from webkit2gtk3-jsc-2.36.= 0-1.fc36.x86_64 > /lib64/libjxl.so.0.6.1 from libjxl-0.6.1-9.fc36.x86_64 > /lib64/libkmldom.so.1.3.0 from libkml-1.3.0-37.fc36.x86_64 > /lib64/libmusicbrainz5.so.1.0.0 from libmusicbrainz5-5.1.0-19.fc36.x8= 6_64 > /lib64/libOpenEXRUtil-3_1.so.30.4.1 from openexr-libs-3.1.4-1.fc36.x8= 6_64 > /lib64/libopenh264.so.2.1.1 from openh264-2.1.1-3.fc36.x86_64 > /lib64/libOSMesa.so.8.0.0 from mesa-libOSMesa-22.0.1-1.fc36.x86_64 > /lib64/libproj.so.22.2.1 from proj-8.2.1-6.fc36.x86_64 > /lib64/libQt5WaylandClient.so.5.15.3 from qt5-qtwayland-5.15.3-1.fc36= .x86_64 > /lib64/libQt5WaylandCompositor.so.5.15.3 from qt5-qtwayland-5.15.3-1.= fc36.x86_64 > /lib64/libQt5XmlPatterns.so.5.15.3 from qt5-qtxmlpatterns-5.15.3-1.fc= 36.x86_64 > /lib64/libSDL2_image-2.0.so.0.2.3 from SDL2_image-2.0.5-8.fc36.x86_64 > /lib64/libstdc++.so.6.0.30 from libstdc++-12.0.1-0.14.fc36.x86_64 > /lib64/libtag.so.1.18.0 from taglib-1.12-6.fc36.x86_64 > /lib64/libreoffice/program/libuno_cppuhelpergcc3.so.3 from libreoffic= e-ure-7.3.2.2-1.fc36.x86_64 > /lib64/libvtkRenderingCore.so.9.1.0 from vtk-9.1.0-6.fc36.x86_64 > /lib64/libwebrtc_audio_processing.so.1.0.0 from webrtc-audio-processi= ng-0.3.1-8.fc36.x86_64 Pfff :-( > There also appears to be some sort of performance regression. I know that= these are your problem children but=20 > /lib64/libmozjs-68.so.0.0.0=20 > /lib64/libwebkit2gtk-4.0.so.37.56.4=20 > /lib64/libgs.so.9.55=20 > /lib64/libperl.so.5.34.1=20 > have been running solidly for more than 3 hours. I=E2=80=99ll let them co= ntinue all night and see if they complete or if they are in some sort of in= finite loop. I see. > The asserts that I mentioned to you privately a few days ago have been cl= eared up. Thank you. > > One of the most common problems in that set of consistency mismatches abo= ve seems to be with C++ destructors. Here are a couple of examples: > $ abidw --abidiff /lib64/libabigail.so.0.0.0 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Functions changes summary: 0 Removed, 2 Changed, 0 Added functions > Variables changes summary: 0 Removed, 0 Changed, 0 Added variable > > 2 functions with some indirect sub-type change: > > [C] 'method virtual abigail::comparison::diff_node_visitor::~diff_node_= visitor()' at abg-comparison.cc:11192:1 has some indirect sub-type changes: > parameter 0 of type 'abigail::comparison::diff_node_visitor* const' w= as removed > > [C] 'method virtual abigail::ir::ir_node_visitor::~ir_node_visitor()' a= t abg-ir.cc:25400:1 has some indirect sub-type changes: > parameter 0 of type 'abigail::ir::ir_node_visitor* const' was removed > > abidw --abidiff /lib64/libaspell.so.15.3.1 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Functions changes summary: 0 Removed, 2 Changed, 0 Added functions > Variables changes summary: 0 Removed, 0 Changed, 0 Added variable > > 2 functions with some indirect sub-type change: > > [C] 'method virtual acommon::CanHaveError::~CanHaveError()' at can_have= _error.cpp:16:1 has some indirect sub-type changes: > parameter 0 of type 'acommon::CanHaveError* const' was removed > > [C] 'method virtual aspeller::Dictionary::~Dictionary()' at data.cpp:80= :1 has some indirect sub-type changes: > parameter 0 of type 'aspeller::Dictionary* const' was removed > > > That accounts for 28 of the 37 consistency mismatches. So that is probabl= y your highest value target to fix before moving on. OK, following your advice, I tracked this down first and indeed this seems related to formal parameters DIEs comparison. I have refreshed the 'fix-dwarf-str-cmp' branch at https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dshortlog;h=3Drefs/heads/= fix-dwarf-str-cmp by adding this patch to the set: https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcommit;h=3D6fa52b7f12b29= f9b92dd0f16b84f70d82cc7c098 I hope this fix will improve things. > There really isn=E2=80=99t a pattern that I can see in the remaining fail= ing cases. Three that you should really focus on are: > abidw --abidiff /lib64/libmozjs-78.so.0.0.0 which is an assert() > #5 0x00007ffff7550596 in __GI___assert_fail (assertion=3D0x7ffff7f2d1a3 = "__abg_cond__", file=3D0x7ffff7f2d5c0 "../../../libabigail/src/abg-ir.cc", = line=3D25414, function=3D0x7ffff7f34b08 "size_t abigail::ir::hash_as_canoni= cal_type_or_constant(const type_base*)") at assert.c:101 > > and=20 > > abidw --abidiff /lib64/libOSMesa.so.8.0.0 which really goes off the rails= somewhere. The indenting goes right off the right side of my jumbo termin= al window. That just ain=E2=80=99t right. I'll be looking at those, thanks. [...] Cheers, --=20 Dodji