mirror of
git://sourceware.org/git/libabigail.git
synced 2025-03-06 22:58:01 +00:00
The Git repository of the Libabigail Project
065247c14c
This is the first patch of a series which aims at fixing bug
libabigail/19097.
The problem in that report is a result of several underlying issues.
This patch series address them in isolation. The patches do not
update the reference output of the regression test as they should,
because they are all needed to get to a sane working state. The test
reference output are thus adjusted in the last patch of the series.
Here are the short titles of the patches of the set, including this
one:
Don't canonicalize types not added to their context in abixml reader
Support updating a class in the abixml reader
Fix emitting of referenced type in abixml writer
Use abidw --abidiff in test-read-dwarf.cc
Adjust regression tests reference output for the current patch set
Below is the cover letter of the first patch of the set.
The abixml reader sometimes (wrongly) canonicalizes types that are not
(yet) added to their context. This can lead to comparison issues
because some information carried by some types are dependant on their
context (e.g, access specifiers) and can be important for type
comparison. Right now, access specifiers for member types are no more
taken into account when comparing member types because DWARF emitters
do not necessarily keep a correct track of those; but when they do, we
better be prepared. And in any case, it's wrong to have type
canonicalization happen on half backed types anyway.
So this patch fixes several spots where type canonicalization happens
on types that are not added to their scope.
* src/abg-reader.cc (read_context::maybe_canonicalize_type):
Assert that a class type that is scheduled for canonicalization
must be in a scope. We do this only for classes, for now. The
assert here helped to spot (and fix) a lot of places where we
were canonicalizing types without scope.
(read_context::build_or_get_type_decl): Canonicalize types here,
when they are built and (hopefully) added to their scope. There
might be cases here where we try to canonicalize types that are
not added to their scope. That should bomb in the assert above,
at least for class types, for now. We'll then fix the places where
the types are created, to make them properly scoped.
(build_type_decl, build_qualified_type_decl)
(build_pointer_type_def, build_reference_type_def)
(build_array_type_def, build_enum_type_decl, build_typedef_decl):
Do not try to canonicalize the types early, right when they are
created. Canonicalization should happen at the point where (or
after) they are added to their scope.
(build_class_decl): Likewise. Also, schedule member types for
canonicalization once they've been added to their scope.
(build_class_tdecl): Schedule the pattern of the class template
for canonicalization once it has been added to its scope. I am
not sure I should do this, as the pattern is not yet a real type,
but I am taking my bet.
(build_type_composition): Schedule the composed type for
canonicalization once it's been added to its scope.
(handle_type_decl, handle_qualified_type_decl)
(handle_pointer_type_def, handle_reference_type_def)
(handle_function_type, handle_array_type_def)
(handle_enum_type_decl, handle_typedef_decl, handle_class_decl):
At this point, we should know if the type is to be added to a
scope or not. If it's in a scope, then schedule for
canonicalization.
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 | ||
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 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.