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 83D883858D28 for ; Wed, 13 Apr 2022 02:19:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83D883858D28 Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-544-2vKYWx-6MSWp2phYLeVFoQ-1; Tue, 12 Apr 2022 22:19:36 -0400 X-MC-Unique: 2vKYWx-6MSWp2phYLeVFoQ-1 Received: by mail-pg1-f199.google.com with SMTP id l14-20020a63f30e000000b0039cc65bdc47so255503pgh.17 for ; Tue, 12 Apr 2022 19:19:36 -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=D6glFOQlYiGFQ+4D1GR5u7dv6mYiO7WT12phh0H2cl0=; b=sr3GDv1/iGfBhxr5+b/skcw+uB/h0AuTqANmMZhzFJrj9DgmoQfTEuQO1AE6kEmRLk UFtmbpy4kviahupLoKg1vhnh0AxBWKCC+mydfYoIKzTPKoqeYaB/swD4+7VerQ8uxBXy XE5uyFOVNb1l9MzvFnuHEnNXquLT1f53VxRqs4soQ+RIbEa5zETRdY+xfbBWklpFtELW aWqkxiffo27CG7j7efJKYlIzcVVHh5GXDb2gaI9QBk9Ij1K3p3UeibdnWeOXUkocrIdr iHBrekaEzEhuuUE9GoSJEghBG9XET1C/c7IdnsK+xgGEZUqFoBOVsiVT5NezTlkDkR01 JanQ== X-Gm-Message-State: AOAM532tZw/QDMNVGxKxwEj7wtbVeWJQISgfQN243VNMLcyDrtcyzW5k vsRxIchq/E2/TNhDien6LBpUF8098FbG5xyHe+vvGAIJyI3x3TjB9lzr9L/+ZBy5bgV3/06opc9 WCYS5zhyzKvH5SKJTD9Sa X-Received: by 2002:a63:6c8a:0:b0:398:5208:220a with SMTP id h132-20020a636c8a000000b003985208220amr33144833pgc.176.1649816374792; Tue, 12 Apr 2022 19:19:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXZU1/4XjOE5LajUkQttTAC4S456IF1sa5ODP2aWb5Ky7gUQJNy6Fm3WizNzhsCn4yxNv0mw== X-Received: by 2002:a63:6c8a:0:b0:398:5208:220a with SMTP id h132-20020a636c8a000000b003985208220amr33144809pgc.176.1649816374232; Tue, 12 Apr 2022 19:19:34 -0700 (PDT) Received: from smtpclient.apple ([47.208.199.57]) by smtp.gmail.com with ESMTPSA id w4-20020a056a0014c400b004fb0c7b3813sm41085600pfu.134.2022.04.12.19.19.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Apr 2022 19:19:33 -0700 (PDT) From: Ben Woodard Message-Id: <04665D9C-C7CB-419C-9DBB-C68D03713D77@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: Tue, 12 Apr 2022 19:19:31 -0700 In-Reply-To: <8735iigtu1.fsf@seketeli.org> Cc: Giuliano Procida 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> 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.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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: Wed, 13 Apr 2022 02:19:42 -0000 So I ran my standard test on this branch as of 3d277a9cc05873cf4aeb97273d58= 5e0b07af917d 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_6= 4 /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.20130812= .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.x= 86_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/libgmpopenh264.= 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.x= 86_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.x86_= 64 /lib64/libOpenEXRUtil-3_1.so.30.4.1 from openexr-libs-3.1.4-1.fc36.x86_= 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.x= 86_64 /lib64/libQt5WaylandCompositor.so.5.15.3 from qt5-qtwayland-5.15.3-1.fc= 36.x86_64 /lib64/libQt5XmlPatterns.so.5.15.3 from qt5-qtxmlpatterns-5.15.3-1.fc36= .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 libreoffice-= 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-processing= -0.3.1-8.fc36.x86_64 There also appears to be some sort of performance regression. I know that t= hese 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 cont= inue all night and see if they complete or if they are in some sort of infi= nite loop. The asserts that I mentioned to you privately a few days ago have been clea= red up. Thank you. One of the most common problems in that set of consistency mismatches above= 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_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 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_e= rror.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 probably = your highest value target to fix before moving on. There really isn=E2=80=99t a pattern that I can see in the remaining failin= g 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", li= ne=3D25414, function=3D0x7ffff7f34b08 "size_t abigail::ir::hash_as_canonica= l_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 s= omewhere. The indenting goes right off the right side of my jumbo terminal= window. That just ain=E2=80=99t right. Then there is the perpetual problem child libstdc++ So keep working on this patch set, let=E2=80=99s get these cleared up and g= et this puppy committed. -ben > On Apr 12, 2022, at 9:16 AM, Dodji Seketeli wrote: >=20 > Giuliano Procida a =C3=A9crit: >=20 >> I started looking at this today but I've run out of time. I'll be able t= o >> take another look in about a week. >=20 > Thanks a lot. >=20 >> Checks fail (various types are renumbered in XML output) starting at >> commit 57b1c714. >=20 > Yeah, that is unfortunately expected because ... >=20 >> I haven't tried this on kernel or framework libraries yet, but I know th= ere >> are plenty of typedefs in both. >=20 > ... of this exactly. >=20 > This typedef change has been on my radar for a long time. The fact that > a type Foo would use a typedef T in one version and a typedef T' in > another once, where T and T' have the same underlying type would result > in the two instances of Foo to be different can wreak havoc on the self > check tests, where in reality the two types are not different from an > ABI standpoint. >=20 > I am hoping that this is one of those changes that will get us closer > to having more stable abixml output. >=20 > Please note however that you need the entire stack of changes to have > everything working "as expected", as far as I can tell. >=20 > Thank you for looking into this. >=20 > --=20 > =09=09Dodji >=20