From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 47C033973062 for ; Thu, 10 Jun 2021 15:36:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47C033973062 Received: by mail-wr1-x434.google.com with SMTP id c9so2824449wrt.5 for ; Thu, 10 Jun 2021 08:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+UtIy+fAuCVDk4GfkEe9i7E4/yg74KHIVKyGpiXyNxI=; b=e1e33EoroQeyPk/pw+QI6Nw9YVmsmvfrEO48z4yPUqt8t1+HR0nA6yhVgCBzXju6vO O0syMVDwAvM5GvxmQKvXTUfZNbiW1wfBgvciFD9uU7HzSvrKDKPANaQN9XBqn/nzS5u7 nbSCa/SwUdKuylMtizG+T5JtfaGeuw6PlHoYdVGeCVEk0ZijtTJDhwknDMrcIvvlRNTP K1g1H8VG9TFc4jpf/GePiGz0EUxmoXQe3vaGVFJZeKIK9e+/LpRcMHtHY7PwNotc/xEw DLfy3RgDfh8yuj7q2MRlkb+SEmVgNu1sIR42YfFrqPLisBAhYogGaLQRyteVbcDzE4An uNlQ== X-Gm-Message-State: AOAM533cdUHqBQ70pmTag84bkBmIKU/RL7A/AbNgbVxyFO82zLdBZKeT s8nhm2tOOqwuLuclvBnTPCqLP3i1xkeCBOMXPImMcslO8Z8= X-Google-Smtp-Source: ABdhPJx+Xq7mW/qR4NxvziHFAAYn1Ursiw8YwlAfbJZD5NUBBcvb+A7CyOKz1p78s6BDCMnlLfo8MRcUqBtT6R2jNZw= X-Received: by 2002:a5d:548b:: with SMTP id h11mr6202420wrv.131.1623339370055; Thu, 10 Jun 2021 08:36:10 -0700 (PDT) MIME-Version: 1.0 References: <87im2m2hpy.fsf@redhat.com> In-Reply-To: <87im2m2hpy.fsf@redhat.com> From: Giuliano Procida Date: Thu, 10 Jun 2021 16:35:57 +0100 Message-ID: Subject: Re: [PATCH, applied] rhbz1951526 - SELF CHECK FAILED for 'gimp-2.10' To: Dodji Seketeli Cc: Giuliano Procida via Libabigail X-Spam-Status: No, score=-22.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" 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: Thu, 10 Jun 2021 15:36:16 -0000 Hi Dodji. This looks really interesting, with some overlap with bugs / changes I've worked on recently. I think I posted a change to simplify the handling of function types as part of another series. I'll be sure to do some checking. In particular, I'll see if regenerating some of the checked-in ABI XML results in fewer duplicate definitions of types and fewer cases where there are both declarations and definitions of types. Giuliano. On Thu, 10 Jun 2021, 10:26 Dodji Seketeli via Libabigail, < libabigail@sourceware.org> wrote: > Hello, > > This is a fix for bug https://bugzilla.redhat.com/show_bug.cgi?id=1951526. > > Although it's a patch for one bug, it addresses several different > issues that cause the observed self comparison failure. As is often > the case on this kind of problems, the failure is difficult to > reproduce on a synthetic test case so I'll explain the root causes in > this commit log. > > There are 4 different root causes to this problem. As I couldn't come > up with a reduced test case for each one of them I am adding the fixes > for those 4 issues in this commit, along with a new regression test > extracted from the initial bugzilla problem report. > > So, overall, the symptom we are seeing here is that when we build an > IR for the input binary gimp-2.0, save that IR into abixml, and read > back that abixml into another IR, comparing the two IR shows changes; > it should show no change whatsoever. This is what we call in > libabigail jargon a self comparison (or self check) failure. > > As alluded to in my introduction above, there appear to be 4 different > root causes for that self comparison failure. > > 1/ The first cause has to do with a situation about two anymous enums > that are (wrongly) considered different from an ABI point of view. > Using the debugging capabilities recently gained by libabigail, I > could notice that the two enums are: > > (gdb) p debug(&l) > enum __anonymous_enum__ : unnamed-enum-underlying-type-32 > { > // size in bits: 32 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/-757de > // @: 0x698fb68, @canonical: 0 > > GIMP_INTERPOLATION_NONE = 0, > GIMP_INTERPOLATION_LINEAR = 1, > GIMP_INTERPOLATION_CUBIC = 2, > GIMP_INTERPOLATION_NOHALO = 3, > GIMP_INTERPOLATION_LOHALO = 4, > }; > > $1 = (abigail::ir::decl_base *) 0x698fba0 > (gdb) p debug(&r) > enum __anonymous_enum__ : unnamed-enum-underlying-type-32 > { > // size in bits: 32 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/app.c > // @: 0xa6d83e8, @canonical: 0 > > GIMP_INTERPOLATION_NONE = 0, > GIMP_INTERPOLATION_LINEAR = 1, > GIMP_INTERPOLATION_CUBIC = 2, > GIMP_INTERPOLATION_NOHALO = 3, > GIMP_INTERPOLATION_LOHALO = 4, > GIMP_INTERPOLATION_LANCZOS = 3, > }; > > $2 = (abigail::ir::decl_base *) 0xa6d8420 > (gdb) > > Note how the second enum has a new enumerator named > 'GIMP_INTERPOLATION_LANCZOS', but its value is '3', which is the exact > same value of as the one of the existing enumerator > GIMP_INTERPOLATION_NOHALO. > > During type canonicalization of the IR from the input binary, > libabigail (wrongly) considers these two enums as being different. > This leads to the type 'Gimp*' (or anything type indirectly using any > one of the anonymous enums above) coming from one translation unit > being considered different from a type 'Gimp*' coming from another > translation unit, just because their are not using either one version > of the anonymous enum above or the other. > > This leads to a *LOT* of spurious type changes from the first IR, that > are saved into abixml. > > To fix this first problem, this patch introduces "two modes" of > comparing enums. There is a binary-only mode which only looks > enumerator values, not enumerator names. And then there is the > source-level mode which looks at both enumerator names and values when > comparing enums. The former mode is used during type > canonicalization. However, when a change is detected between two > enums, then the diff-IR built to describe the change is constructed > using the later mode. Using the later mode allows to describe > precisely things like enumerator insertion/removal by referring to the > names of the added/removed enumerators. > > 2/ The second root cause is that a struct, say, 'struct _GimpImage' > from a translation unit is considered different from a 'struct > _GimpImage' because the DWARF reader wrongly assign them different sizes. > > Here is what it looks like in the debugger: > > (gdb) p debug(&l) > struct _GimpImage > { // size in bits: 384 > // definition point: ../../app/core/gimpimage.h:39:1 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/-757de > // @: 0x69b9d10, @canonical: 0 > > GimpViewable parent_instance;' > Gimp* gimp;' > GimpImagePrivate* priv;' > }; > > $8 = (abigail::ir::type_base *) 0x69b9d10 > (gdb) p debug(&r) > struct _GimpImage > { // size in bits: 0 > // definition point: :0:0 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/-8813f > // @: 0x6ac7a50, @canonical: 0 > > }; > > Notice how the second 'struct _GimpImage' has a size of zero. > > This is because when reading the DWARF, we first encounter the DIE for > the first' struct _GimpImage' and we properly build a type for it, > along with its declaration. Then when we encounter another DIE > defining 'struct _GimpImage' again, from a different translation unit, > the DWARF reader recognizes that it's a DIE for a declaration of > 'struct _GimpImage' and fails to re-use the previous definition for > 'struct _GimpImage'. So it wrongly builds declaration-only 'struct > _GimpImage' for it, hence the second struct _GimpImage with a zero > size. > > Here again that creates spurious changes (after type canonicalization) > in types using struct _GimpImage. And that is a lot of types, > including things like 'Gimp*' and the like. > > The fix for this root cause issue is to change > add_or_update_class_type in the DWARF reader to recognize that we are > seeing a type declaration for which there was already a definition and > return that definition instead of creating a new declaration. > > 3/ The third root cause is better explained with a "screen shot". > Consider these two 'versions' of the same struct _GdkDevice from two > different translation units: > > struct _GdkDevice > { // size in bits: 576 > // definition point: /usr/include/gtk-2.0/gdk/gdkinput.h:98:1 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/-2d0352 > // @: 0x8820530, @canonical: 0 > > GObject parent_instance;' > gchar* name; // uses canonical type '@0x6892980' > GdkInputSource source;' > GdkInputMode mode;' > gboolean has_cursor; // uses canonical type '@0x688dd00' > gint num_axes; // uses canonical type '@0x688dd00' > GdkDeviceAxis* axes;' > gint num_keys; // uses canonical type '@0x688dd00' > GdkDeviceKey* keys;' > }; > > $9 = (abigail::ir::type_base *) 0x8820530 > (gdb) p debug(&r) > struct _GdkDevice > { // size in bits: 576 > // definition point: /usr/include/gtk-2.0/gdk/gdkinput.h:98:1 > // translation unit: > /usr/src/debug/gimp-2.10.22-2.el9.1.aarch64/app/-1fdb18 > // @: 0x7cd71e0, @canonical: 0 > > GObject parent_instance;' > gchar* _g_sealed__name; // uses canonical type '@0x6892980' > GdkInputSource _g_sealed__source;' > GdkInputMode _g_sealed__mode;' > gboolean _g_sealed__has_cursor; // uses canonical type '@0x688dd00' > gint _g_sealed__num_axes; // uses canonical type '@0x688dd00' > GdkDeviceAxis* _g_sealed__axes;' > gint _g_sealed__num_keys; // uses canonical type '@0x688dd00' > GdkDeviceKey* _g_sealed__keys;' > }; > > $10 = (abigail::ir::type_base *) 0x7cd71e0 > (gdb) > > Notice how the name of the second data member 'name' was changed to > '_g_sealed_name'. A similar scheme happens to several other data > member names. The offsets and types of the struct _GdkDevice haven't > changed however. So from an ABI standpoint, the two versions of that > struct are equal. Libabigail consider them different however. > Because that type is used by tons of other types of the binary being > analyzed, this leads to lots of spurious canonical type difference > that shouldn't be there. > > These three issues are magnified by the fact that the gimp binary is > compiled using "link time optimization". That brings in a lot more > opportunities to see these underlying issues that have been there for > a long time. > > 4/ The fourth and last root cause issue. When the abixml writer emits > a translation unit (TU), it keeps track of the 'non-emitted referred > to type' of the currently emitted translation unit and emits them at > the end of each TU. For instance, if the type 'Gimp*' (pointer to > Gimp) was emitted, and yet the referred-to type 'Gimp' wasn't emitted, > the TU writer makes sure to emit the referred-to 'Gimp' type at the > end of the TU. This has been going on for quite some time now. > > The problem however is that although the non-emitted referred-to type > was referred to in this current TU, it might no have been *DEFINED* in > this TU. In that case, it should not be emitted in this TU. > > Otherwise, the TU where that type is defined in the abixml might > appear different from where it is defined in the initial binary, > leading to self comparison failures down the road. > > This patch ensures that a non-emitted referred-to type is always > emitted in the TU it belongs to. > > 5/ After doing all this, it appears that we were forgetting to emit > some function types that were defined in TUs emitted earlier and yet > were being referred-to later. Looking closer, I realized that we > should just emit function types seen in a given TU, regardless of the > referred-to relation. > > The problem with that is that function types are special in libabigail > because there are two situation in which they are created. > > Basically, a function type is created by the DWARF DIE > DW_TAG_subroutine_type. This is for instance how pointer to functions > are represented in DWARF, namely, by a DW_TAG_pointer_type that points > to a DW_TAG_subroutine_type. That is represented in the libabigail ir > by an instance of the abigail::ir::function_type type. This is > represented in abixml as a 'function-type' XML element. > > But then, libabigail considers that all decls have a type. This > applies obviously for variables or data member. Right. But then, > libabigail considers that a function is also a decl, which has a type. > And the type of a function is a function type, represented by the same > abigail::ir::function_type. A practical difference with the former > situation is that function decls are *NOT* represented in abixml using > a 'function-type' element. Instead a 'function-decl' XML element uses > return type and parameter elements to represent the types involved > with a function decl. > > Said otherwise, the former 'function type' concept used to represent > the type of functions in the libabigail IR is artificial. This > artificial-ness was not explicitly expressed in libabigail. This > patch now expresses that artificial-ness for function types. So the > abixml writer now just decide to not emit artificial function types, > and instead, emit all the non-artificial function types instead. > > This addresses this last issues by being able to emit all > non-artificial function types defined in a given TU, without having to > bother with the fact that they are referred-to or not. > > Together, fixing these 5 problems fixes this reported problem. > > The changes to the reference test outputs are adjustments needed > because of the abixml output indeed changes. > > * include/abg-ir.h > (environment::use_enum_binary_only_equality): Declare > accessors. (type_or_decl_base::{s,g}et_is_artificial): > Likewise. (decl_base::{s,g}et_is_artificial): Remove > accessors. * src/abg-ir.cc > (environment::priv::use_enum_binary_only_equality): Define new > data member. > (environment::priv::use_enum_binary_only_equality): Define > accessors. (type_or_decl_base::priv::is_artificial_): Define > new data member. It has actually moved here from > decl_base::priv::is_artificial_. > (type_or_decl_base::priv::priv): Initialize it. > (type_or_decl_base::{g,s}et_is_artificial): Define accessors. > (decl_base::is_artificial_): Move this to > type_or_decl_base::is_artificial_. > (maybe_adjust_canonical_type): In a given class of equivalence > of function types, if there is one non-artificial function > type, then the entire class of equivalence is considered > non-artificial; so flag the canonical function type as being > non-artificial. (is_enumerator_present_in_enum): Define new > static function. (equals): Re-arrange the overload for enums > so the order of the enumerators doesn't count in the > comparison. Also, two enums with different numbers of > enumerators can still be equal, with the right redundancy. In > the overload for var_decl, avoid taking into account the names > of data members in the comparison. > (enum_type_decl::enumerator::operator==): In the binary-level > comparison mode, only compare the value of enumerators, not > their name. * src/abg-comparison.cc (compute_diff): In the > overload for enum_type_decl, if the enums compare different > using binary-level comparison, then use source-level > comparison to build the diff-IR. * src/abg-dwarf-reader.cc > (read_context::compare_before_canonicalisation): Compare enums > using binary-level comparison. (add_or_update_class_type): If > we are looking at the definition of an existing declaration > that has been already defined then use the previous > definition, in case we are going to need to update the > definition. Also, update the size only if it's needed. > (build_function_type): By default, consider the newly built > function type as artificial. (build_ir_node_from_die): When > looking at a DW_TAG_subroutine_type DIE, consider the built > function type as non-artificial. * src/abg-reader.cc > (read_context::maybe_check_abixml_canonical_type_stability): > Don't consider declaration-only classes in an ODR context > because they don't have canonical types. > (build_function_decl): Flag the function type of the function > as artificial. (build_class_decl): Make sure to reuse class > types that were already created. * src/abg-writer.cc > (write_translation_unit): Allow emitting empty classes. Make > sure referenced types are emitting in the translation unit > where they belong. Avoid emitting artificial function types. > * > > tests/data/test-alt-dwarf-file/rhbz1951526/rhbz1951526-report-0.txt: > New test reference output. * > tests/data/test-alt-dwarf-file/rhbz1951526/usr/bin/gimp-2.10: > New reference test binary input. * > > tests/data/test-alt-dwarf-file/rhbz1951526/usr/lib/debug/.dwz/gimp-2.10.22-2.el9.1.aarch64: > Likewise. * > > tests/data/test-alt-dwarf-file/rhbz1951526/usr/lib/debug/usr/bin/gimp-2.10-2.10.22-2.el9.1.aarch64.debug: > Likewise. * tests/data/Makefile.am: Add the new test files to > source directory. * tests/test-alt-dwarf-file.cc: Add the new > test inputs to this test harness. * > tests/data/test-abidiff/test-PR18791-report0.txt: Adjust. * > tests/data/test-abidiff/test-enum0-report.txt: Likewise. * > tests/data/test-annotate/libtest23.so.abi: Likewise. * > tests/data/test-annotate/libtest24-drop-fns-2.so.abi: > Likewise. * > tests/data/test-annotate/libtest24-drop-fns.so.abi: Likewise. > * tests/data/test-annotate/test-anonymous-members-0.o.abi: > Likewise. * tests/data/test-annotate/test13-pr18894.so.abi: > Likewise. * tests/data/test-annotate/test14-pr18893.so.abi: > Likewise. * tests/data/test-annotate/test15-pr18892.so.abi: > Likewise. * tests/data/test-annotate/test17-pr19027.so.abi: > Likewise. * > > tests/data/test-annotate/test18-pr19037-libvtkRenderingLIC-6.1.so.abi: > Likewise. * > > tests/data/test-annotate/test19-pr19023-libtcmalloc_and_profiler.so.abi: > Likewise. * > > tests/data/test-annotate/test20-pr19025-libvtkParallelCore-6.1.so.abi: > Likewise. * tests/data/test-annotate/test21-pr19092.so.abi: > Likewise. * > > tests/data/test-diff-dwarf-abixml/test0-pr19026-libvtkIOSQL-6.1.so.1.abi: > Likewise. * > tests/data/test-diff-dwarf/PR25058-liblttng-ctl-report-1.txt: > Likewise. * tests/data/test-diff-dwarf/test6-report.txt: > Likewise. * > tests/data/test-diff-filter/test31-pr18535-libstdc++-report-0.txt: > Likewise. * > tests/data/test-diff-filter/test31-pr18535-libstdc++-report-1.txt: > Likewise. * tests/data/test-diff-filter/test8-report.txt: > Likewise. * > > tests/data/test-diff-pkg/spice-server-0.12.4-19.el7.x86_64-0.12.8-1.el7.x86_64-report-2.txt: > Likewise. * > > tests/data/test-diff-pkg/spice-server-0.12.4-19.el7.x86_64-0.12.8-1.el7.x86_64-report-3.txt: > Likewise. * > > tests/data/test-diff-pkg/tbb-4.1-9.20130314.fc22.x86_64--tbb-4.3-3.20141204.fc23.x86_64-report-0.txt: > Likewise. * > > tests/data/test-diff-pkg/tbb-4.1-9.20130314.fc22.x86_64--tbb-4.3-3.20141204.fc23.x86_64-report-1.txt: > Likewise. * > tests/data/test-read-dwarf/PR22015-libboost_iostreams.so.abi: > Likewise. * > tests/data/test-read-dwarf/PR22122-libftdc.so.abi: Likewise. > * tests/data/test-read-dwarf/PR25007-sdhci.ko.abi: Likewise. > * > > tests/data/test-read-dwarf/PR25042-libgdbm-clang-dwarf5.so.6.0.0.abi: > Likewise. * > tests/data/test-read-dwarf/PR26261/PR26261-exe.abi: Likewise. > * tests/data/test-read-dwarf/libtest23.so.abi: Likewise. * > tests/data/test-read-dwarf/libtest24-drop-fns-2.so.abi: > Likewise. * > tests/data/test-read-dwarf/libtest24-drop-fns.so.abi: > Likewise. * > tests/data/test-read-dwarf/test-libandroid.so.abi: Likewise. > * tests/data/test-read-dwarf/test10-pr18818-gcc.so.abi: > Likewise. * tests/data/test-read-dwarf/test12-pr18844.so.abi: > Likewise. * tests/data/test-read-dwarf/test13-pr18894.so.abi: > Likewise. * tests/data/test-read-dwarf/test14-pr18893.so.abi: > Likewise. * tests/data/test-read-dwarf/test15-pr18892.so.abi: > Likewise. * tests/data/test-read-dwarf/test16-pr18904.so.abi: > Likewise. * tests/data/test-read-dwarf/test17-pr19027.so.abi: > Likewise. * > > tests/data/test-read-dwarf/test18-pr19037-libvtkRenderingLIC-6.1.so.abi: > Likewise. * > > tests/data/test-read-dwarf/test19-pr19023-libtcmalloc_and_profiler.so.abi: > Likewise. * > > tests/data/test-read-dwarf/test20-pr19025-libvtkParallelCore-6.1.so.abi: > Likewise. * tests/data/test-read-dwarf/test21-pr19092.so.abi: > Likewise. * > > tests/data/test-read-dwarf/test22-pr19097-libstdc++.so.6.0.17.so.abi: > Likewise. * > tests/data/test-read-dwarf/test9-pr18818-clang.so.abi: > Likewise. * > tests/data/test-read-write/test28-without-std-fns-ref.xml: > Likewise. * > tests/data/test-read-write/test28-without-std-vars-ref.xml: > Likewise. > > Signed-off-by: Dodji Seketeli > Applied to master. > --- > include/abg-ir.h | 18 +- > src/abg-comparison.cc | 22 +- > src/abg-dwarf-reader.cc | 15 +- > src/abg-ir.cc | 269 +- > src/abg-reader.cc | 18 +- > src/abg-writer.cc | 53 +- > tests/data/Makefile.am | 4 + > .../test-abidiff/test-PR18791-report0.txt | 131 +- > tests/data/test-abidiff/test-enum0-report.txt | 11 - > .../rhbz1951526/rhbz1951526-report-0.txt | 0 > .../rhbz1951526/usr/bin/gimp-2.10 | Bin 0 -> 10130448 bytes > .../debug/.dwz/gimp-2.10.22-2.el9.1.aarch64 | Bin 0 -> 4322303 bytes > .../gimp-2.10-2.10.22-2.el9.1.aarch64.debug | Bin 0 -> 36366520 bytes > tests/data/test-annotate/libtest23.so.abi | 4 +- > .../test-annotate/libtest24-drop-fns-2.so.abi | 4 +- > .../test-annotate/libtest24-drop-fns.so.abi | 4 +- > .../test-anonymous-members-0.o.abi | 34 +- > .../data/test-annotate/test13-pr18894.so.abi | 1014 +- > .../data/test-annotate/test14-pr18893.so.abi | 8102 +-- > .../data/test-annotate/test15-pr18892.so.abi | 26303 ++++---- > .../data/test-annotate/test17-pr19027.so.abi | 16960 ++--- > ...st18-pr19037-libvtkRenderingLIC-6.1.so.abi | 10852 ++- > ...19-pr19023-libtcmalloc_and_profiler.so.abi | 16895 ++--- > ...st20-pr19025-libvtkParallelCore-6.1.so.abi | 34205 +++++----- > .../data/test-annotate/test21-pr19092.so.abi | 4546 +- > .../test0-pr19026-libvtkIOSQL-6.1.so.1.abi | 13978 ++-- > .../PR25058-liblttng-ctl-report-1.txt | 24 +- > tests/data/test-diff-dwarf/test6-report.txt | 12 - > .../test31-pr18535-libstdc++-report-0.txt | 34 +- > .../test31-pr18535-libstdc++-report-1.txt | 34 +- > tests/data/test-diff-filter/test8-report.txt | 3 - > ...l7.x86_64-0.12.8-1.el7.x86_64-report-2.txt | 6 +- > ...l7.x86_64-0.12.8-1.el7.x86_64-report-3.txt | 4 +- > ...bb-4.3-3.20141204.fc23.x86_64-report-0.txt | 110 +- > ...bb-4.3-3.20141204.fc23.x86_64-report-1.txt | 4 +- > .../PR22015-libboost_iostreams.so.abi | 36 +- > .../test-read-dwarf/PR22122-libftdc.so.abi | 931 +- > .../data/test-read-dwarf/PR25007-sdhci.ko.abi | 137 + > .../PR25042-libgdbm-clang-dwarf5.so.6.0.0.abi | 814 +- > .../test-read-dwarf/PR26261/PR26261-exe.abi | 4 - > tests/data/test-read-dwarf/libtest23.so.abi | 2 +- > .../libtest24-drop-fns-2.so.abi | 2 +- > .../test-read-dwarf/libtest24-drop-fns.so.abi | 2 +- > .../test-read-dwarf/test-libandroid.so.abi | 4150 +- > .../test-read-dwarf/test10-pr18818-gcc.so.abi | 2179 +- > .../test-read-dwarf/test12-pr18844.so.abi | 4623 +- > .../test-read-dwarf/test13-pr18894.so.abi | 917 +- > .../test-read-dwarf/test14-pr18893.so.abi | 6494 +- > .../test-read-dwarf/test15-pr18892.so.abi | 22057 +++--- > .../test-read-dwarf/test16-pr18904.so.abi | 15595 ++--- > .../test-read-dwarf/test17-pr19027.so.abi | 14535 ++-- > ...st18-pr19037-libvtkRenderingLIC-6.1.so.abi | 7643 +-- > ...19-pr19023-libtcmalloc_and_profiler.so.abi | 12826 ++-- > ...st20-pr19025-libvtkParallelCore-6.1.so.abi | 18693 +++--- > .../test-read-dwarf/test21-pr19092.so.abi | 3952 +- > .../test22-pr19097-libstdc++.so.6.0.17.so.abi | 55345 ++++++---------- > .../test9-pr18818-clang.so.abi | 2092 +- > .../test28-without-std-fns-ref.xml | 2 +- > .../test28-without-std-vars-ref.xml | 2 +- > tests/test-alt-dwarf-file.cc | 7 + > 60 files changed, 121315 insertions(+), 185398 deletions(-) > create mode 100644 > tests/data/test-alt-dwarf-file/rhbz1951526/rhbz1951526-report-0.txt > create mode 100755 > tests/data/test-alt-dwarf-file/rhbz1951526/usr/bin/gimp-2.10 > create mode 100644 > tests/data/test-alt-dwarf-file/rhbz1951526/usr/lib/debug/.dwz/gimp-2.10.22-2.el9.1.aarch64 > create mode 100644 > tests/data/test-alt-dwarf-file/rhbz1951526/usr/lib/debug/usr/bin/gimp-2.10-2.10.22-2.el9.1.aarch64.debug > > The patch itself is way too big to fit here so you can read it at: > > https://sourceware.org/git/?p=libabigail.git;a=commit;h=1cfbff1b3037d1049bdff7e86de27c3a86af23b3 > > > -- > Dodji > >