mirror of
git://sourceware.org/git/libabigail.git
synced 2024-12-19 16:30:04 +00:00
The Git repository of the Libabigail Project
28c77a8b4b
It appears now that forcing unresolved class declarations to be declared is not a good idea. It's better to just leave them as is, and they'll have a hash value of zero. We were forcing them to be defined (with a size of 1) because they were used as base classes. It appears that GCC and Clang (at least) allow base classes to be non-complete, in case the base class has a vtable; in that case, the full debug info of the base class would be emitted in another DSO, where the vtable is emitted, making the base class be complete from a debug info standpoint. So it's better for us to be in par with that vision. Furthermore, one of the reasons why they were not resolved, most of the time, was that the resolution code was buggy; and that has been fixed in a patch applied very recently. So this patch removes the forcing code. The patch also fixes the handling of class declaration during the parsing. Basically, bugs in some versions of Clang are so that we cannot completely trust the DW_AT_declaration property on a class. What we do is that when we see that property, we flag the class as being a declaration. But then if there is a DW_AT_byte_size property, the class is considered as being defined. We were being over-zealous in considering the class as being defined, because having a member function was enough; this patch now only considers the presence of a *virtual* member functions, data members, base classes or a DW_AT_byte_size as being conditions for being defined. * src/abg-dwarf-reader.cc (read_context::decl_only_classes_map_): Remove this data member. (read_context::{declaration_only_classes_to_force_defined, schedule_declaration_only_class_for_forced_resolution}): Remove these member functions. (read_context::resolve_declaration_only_classes): Do not force resolution of class declaration. (build_class_type_and_add_to_ir): Do not schedule classes for forced-resolution when they are used as base classes. The presence of a member function is not enough to make the class be defined. It needs to be a virtual member function. Signed-off-by: Dodji Seketeli <dodji@redhat.com> |
||
---|---|---|
doc | ||
include | ||
m4 | ||
scripts | ||
src | ||
tests | ||
tools | ||
.gitignore | ||
abigail.m4 | ||
AUTHORS | ||
ChangeLog | ||
COMMIT-LOG-GUIDELINES | ||
COMPILING | ||
config.h.in | ||
configure.ac | ||
CONTRIBUTING | ||
COPYING | ||
COPYING-GPLV3 | ||
COPYING-LGPLV2 | ||
COPYING-LGPLV3 | ||
gen-changelog.py | ||
install-sh | ||
libabigail.pc.in | ||
ltmain.sh | ||
Makefile.am | ||
README | ||
test21-type-suppr-0.suppr | ||
test21-type-suppr-report-0.txt |
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, fonctions 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 comparing two ABI Corpuses, 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.