mirror of
git://sourceware.org/git/libabigail.git
synced 2025-03-05 06:07:49 +00:00
The Git repository of the Libabigail Project
When comparing two aggregates A and B, it can happen that has a sub-type of A is itself; similarly for B. This is a cycle in the type graph, obviously. Also, A and B are said to be recursive types. Structally comparing two recursive types (i.e, comparing them member-wise) can lead to an endless loop. So, during type canonicalization, comparison cycles must be detected to avoid those endless loop. This is currently done in the equals() overload for class_decl, union_decl, class_or_union as well as function_type. Those are the aggregate types that are subject to these cycles when comparing recursive types. Currently, detecting comparison cycles is based on ir::environment::priv::mark_as_being_compared(), ir::environment::priv::priv::unmark_as_being_compared(), ir::environment::priv::comparison_started() considering the pair of pointer to aggregate types being currently compared. If that pair appears more than once in the stack of aggregates being compared a cycle is detected. But then, watching the stack of aggregates during the analsysis of the /usr/lib64/libgs.so.9 binary from the ghostscript-9.52-5.oe1.x86_64 package from https://sourceware.org/bugzilla/show_bug.cgi?id=29857 it appears that the stack of aggregates (structs) was growing endlessly, when comparing the "struct gs_memory_s" type, and the same struct gs_memory_s aggregate was appearing several times on the right-hand side of the comparison stack. Clearly, this is a comparison cycle. The gs_memory struct is appearing several times as the right hand side operand in the stack of operands being compared, even though no pair of operands being compared was present more than once. This prompted me to use another heuristic to detect comparison cycles: If the same aggregate type is appearing several times on either the left or right hand side of the comparison stack then a cycle is detected. This fixes the cycle detection failure above and comparing the two binaries completes in ~ 43 minutes on my laptop, with a non optimized libabigail build. * src/abg-ir-priv.h (class_set_type, fn_set_type): Define new typedefs. * src/abg-ir.cc (environment::priv::{left_classes_being_compared_, right_classes_being_compared_, left_fn_types_being_compared_, right_fn_types_being_compared_}): Define new data members. (environment::priv::{classes_being_compared_, fn_types_being_compared_}): Erase data members. (environment::priv::{dump_classes_being_compared, dump_fn_types_being_compared}): Erase member functions. (environment::priv::{mark_as_being_compared, unmark_as_being_compared, comparison_started}): Change this to use the left-hand-side and right-hand-side comparison stack introduced above. (dump_classes_being_compared, dump_fn_types_being_compared): Remove functions. Signed-off-by: Dodji Seketeli <dodji@seketeli.org> |
||
---|---|---|
.github | ||
autoconf-archive | ||
bash-completion | ||
doc | ||
docker | ||
include | ||
m4 | ||
relicensing-scripts | ||
scripts | ||
src | ||
tests | ||
tools | ||
.clang-format | ||
.gitignore | ||
.mailmap | ||
abigail.m4 | ||
ABIXML-FORMAT-VERSIONS | ||
AUTHORS | ||
ChangeLog | ||
COMMIT-LOG-GUIDELINES | ||
COMPILING | ||
configure.ac | ||
CONTRIBUTING | ||
default.abignore | ||
gen-changelog.py | ||
install-sh | ||
libabigail.pc.in | ||
license-change-2020.txt | ||
LICENSE.txt | ||
ltmain.sh | ||
Makefile.am | ||
NEWS | ||
README | ||
README-DOCKER.md | ||
release-text-template.txt | ||
update-copyright.sh | ||
VISIBILITY |
This is the Application Binary Interface Generic Analysis and Instrumentation Library. It aims at constructing, manipulating, serializing and de-serializing ABI-relevant artifacts. The set of artifacts that we are intersted is made of quantities like types, variable, functions and declarations of a given library or program. For a given library or program this set of quantities is called an ABI corpus. This library aims at (among other things) providing a way to compare two ABI Corpora (apparently the plural of corpus is copora, heh, that's cool), provide detailed information about their differences, and help build tools to infer interesting conclusions about these differences. You are welcome to contribute to this project after reading the files CONTRIBUTING and COMMIT-LOG-GUIDELINES files in the source tree. Communicating with the maintainers of this project -- including sending patches to be include to the source code -- happens via email at libabigail@sourceware.org.