mirror of
git://sourceware.org/git/libabigail.git
synced 2025-03-06 06:37:31 +00:00
The Git repository of the Libabigail Project
91680cc597
Until now, the canonical DIE offsets map (the map that associates a
canonical DIE offset to a given DIE offset) was implemented in the
DWARF reader by using vectors. This proves to use a lot of memory
(more than 25GB!!) for huge vmlinux binaries. So much that the thing
was too slow (hey, yeah, because it was swapping out!) on vmlinux
kernel binary of 3GB of size, just to abidw it out.
This patch changes that to use an unordered map for this. It now uses
~ 4GB of peak RAM memory, so I can actually abidw the vmlinux of 3GB
of size on my laptop. It's still taking 16 minutes (!!) to complete,
but at least it's progress, as it's completed at least, without
swapping out.
And it doesn't see to noticeably slowdown the test suite.
* src/abg-dwarf-reader.cc
(read_context::canonical_type_die_offsets_): Renamed the
canonical_type_die_vecs_ data member into this.
(read_context::canonical_decl_die_offsets_): Renamed the
canonical_decl_die_vecs_ data member into this.
(read_context::{initialize, compute_canonical_die_offset,
compute_canonical_die, get_canonical_die,
get_or_compute_canonical_die, set_canonical_die_offset,
get_canonical_die_offset}): Adjust.
Signed-off-by: Dodji Seketeli <dodji@redhat.com>
|
||
|---|---|---|
| autoconf-archive | ||
| bash-completion | ||
| doc | ||
| include | ||
| m4 | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| abigail.m4 | ||
| AUTHORS | ||
| ChangeLog | ||
| COMMIT-LOG-GUIDELINES | ||
| COMPILING | ||
| configure.ac | ||
| CONTRIBUTING | ||
| COPYING | ||
| COPYING-GPLV3 | ||
| COPYING-LGPLV2 | ||
| COPYING-LGPLV3 | ||
| default.abignore | ||
| gen-changelog.py | ||
| install-sh | ||
| libabigail.pc.in | ||
| ltmain.sh | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| release-text-template.txt | ||
| 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, 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.