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 ACF843858C52 for ; Mon, 18 Apr 2022 16:42:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACF843858C52 Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-318-dYCyf3-iPEqOBFtdehVfFA-1; Mon, 18 Apr 2022 12:42:15 -0400 X-MC-Unique: dYCyf3-iPEqOBFtdehVfFA-1 Received: by mail-pj1-f69.google.com with SMTP id x3-20020a17090a530300b001d0e5927c83so5571187pjh.7 for ; Mon, 18 Apr 2022 09:42:15 -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:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PQttPSbYwfFo8PYJ6RTPqBM+xx6jji6UI2tNzPy+Hl8=; b=e3AU4jmEVgBOGUyd98ooxt1lizbKmc5w+Z9BIQJSQFz3BjTv1SjHmS/L3IgHMeIrAF 0gOWCWGnVLSsKGA0m5vdpj7WBcGeFANBa0zyMunpmZr+NxEER0NQbo848TFQiWreweVD B/lyci8LtR5C+GGSPOUGsrvStCFTIBy99k9QXmS3CoGI4mHbAFRoXWGsWTC+YLHpQjoG rXDynoh6AcFw2Xcml6umNf0+0oXR7rHNxwClGMe/JsLkSsL6IQUvnKMtXTxPvaIZWDHb 2bLlBvFEd2DD26LM7ZrRqYjR56za439+vS3jaDnIyFV1UWYNCAtCIZsxYW/OpxyJQ48U nMTw== X-Gm-Message-State: AOAM530zSitDyIBuyL8I2vXpATBtHcikssTMy0G7qNPvAn6SD98TKLZj 4ZEapvySDAWqErjXaqxxBPslwBEuj3MCTzQpTh9hqhoj4NfL47GSvU1IjCz+CgDRYRSdFyOYlfT flnylflLs+fhFUOl2Wgxv X-Received: by 2002:a63:a902:0:b0:398:cdd3:f85e with SMTP id u2-20020a63a902000000b00398cdd3f85emr10896513pge.122.1650300134244; Mon, 18 Apr 2022 09:42:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkqatnDtE6s1IIT5Fnke5ujZVAC+EGyd0dMjHR9tom2FXf0FBkNnu27z6xEUce/MKKBfn/UA== X-Received: by 2002:a63:a902:0:b0:398:cdd3:f85e with SMTP id u2-20020a63a902000000b00398cdd3f85emr10896487pge.122.1650300133698; Mon, 18 Apr 2022 09:42:13 -0700 (PDT) Received: from smtpclient.apple ([47.208.199.57]) by smtp.gmail.com with ESMTPSA id a38-20020a056a001d2600b004f72acd4dadsm13457840pfx.81.2022.04.18.09.42.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Apr 2022 09:42:13 -0700 (PDT) From: Ben Woodard Message-Id: <02FAADA5-A8AF-4AA9-8B58-B8A55F101088@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: 'src/abg-dwarf-reader.cc:compare_dies_string_attribute_value' optimization Date: Mon, 18 Apr 2022 09:42:10 -0700 In-Reply-To: <86sfqg10xl.fsf@seketeli.org> Cc: Ben Woodard via Libabigail To: Dodji Seketeli 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> <86sfqg10xl.fsf@seketeli.org> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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, HTML_MESSAGE, KAM_LOTSOFHASH, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 Apr 2022 16:42:20 -0000 > On Apr 14, 2022, at 2:14 AM, Dodji Seketeli wrote: >=20 > Hey Ben! >=20 > Man, thanks a LOT for doing this. >=20 > Please see my comments below. >=20 > Ben Woodard > a =C3=A9crit= : >=20 >> So I ran my standard test on this branch as of 3d277a9cc05873cf4aeb97273= d585e0b07af917d >>=20 >> 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_6= 4 >> /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 >=20 > Pfff :-( >=20 >> There also appears to be some sort of performance regression. I know tha= t 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 c= ontinue all night and see if they complete or if they are in some sort of i= nfinite loop. >=20 > I see. >=20 >> The asserts that I mentioned to you privately a few days ago have been c= leared up. Thank you. >>=20 >> One of the most common problems in that set of consistency mismatches ab= ove 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 >>=20 >> 2 functions with some indirect sub-type change: >>=20 >> [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 >>=20 >> [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 >>=20 >> 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 >>=20 >> 2 functions with some indirect sub-type change: >>=20 >> [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 >>=20 >> [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 >>=20 >>=20 >> That accounts for 28 of the 37 consistency mismatches. So that is probab= ly your highest value target to fix before moving on. >=20 > 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/head= s/fix-dwarf-str-cmp > by adding this patch to the set: > https://sourceware.org/git/?p=3Dlibabigail.git;a=3Dcommit;h=3D6fa52b7f12b= 29f9b92dd0f16b84f70d82cc7c098 >=20 > I hope this fix will improve things. I=E2=80=99m not sure that it worked. For example: $ cat libabigail.so.0.0.0.out=20 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_vi= sitor()' at abg-comparison.cc:11192:1 has some indirect sub-type changes: parameter 0 of type 'abigail::comparison::diff_node_visitor* const' was= removed [C] 'method virtual abigail::ir::ir_node_visitor::~ir_node_visitor()' at = abg-ir.cc:25400:1 has some indirect sub-type changes: parameter 0 of type 'abigail::ir::ir_node_visitor* const' was removed $ cat libadwaitaqtpriv.so.1.4.1.out Functions changes summary: 0 Removed, 1 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 1 function with some indirect sub-type change: [C] 'method virtual Adwaita::TransitionData::~TransitionData()' at adwait= atransitiondata.h:48:1 has some indirect sub-type changes: implicit parameter 0 of type 'Adwaita::TransitionData* const' changed: entity changed from 'Adwaita::TransitionData* const' to 'Adwaita::Tra= nsitionData*' type size hasn't changed parameter 1 of type 'int' was added I still have 36 consistency mismatches. All of them see to include virtual = destructors. >=20 >> There really isn=E2=80=99t a pattern that I can see in the remaining fai= ling 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 <= http://abg-ir.cc/>", line=3D25414, function=3D0x7ffff7f34b08 "size_t abigai= l::ir::hash_as_canonical_type_or_constant(const type_base*)") at assert.c:1= 01 >>=20 >> and=20 >>=20 >> abidw --abidiff /lib64/libOSMesa.so.8.0.0 which really goes off the rail= s somewhere. The indenting goes right off the right side of my jumbo termi= nal window. That just ain=E2=80=99t right. >=20 > I'll be looking at those, thanks. >=20 > [...] >=20 > Cheers, >=20 > --=20 > =09=09Dodji