mirror of
git://sourceware.org/git/libabigail.git
synced 2024-12-17 15:34:34 +00:00
The Git repository of the Libabigail Project
7b35e89315
In this bug, the DWARF debug info of the binary (generated by Intel's
ICC compiler) has interesting constructs like:
[ 6b5a0] subprogram
decl_line (data2) 787
decl_column (data1) 15
decl_file (data1) 46
declaration (flag)
accessibility (data1) public (1)
type (ref4) [ 6b56a]
prototyped (flag)
name (string) "ldiv"
MIPS_linkage_name (string) "ldiv"
[ 6b5b6] formal_parameter
type (ref4) [ 5f2aa]
name (string) "$Ë2"
[ 6b5bf] formal_parameter
type (ref4) [ 5f2aa]
name (string) "$Ë3"
Note the strings that make up the name of the formal parameters of the
function, near the end:
[ 6b5b6] formal_parameter
type (ref4) [ 5f2aa]
name (string) "$Ë2"
[ 6b5bf] formal_parameter
type (ref4) [ 5f2aa]
name (string) "$Ë3"
The strings "$Ë2" and $Ë3" (which are the names of the
parameters of the function) are garbage.
Libabigail's DWARF reader naively uses those strings as names for the
function parameters, in the type of the function.
Then, the abixml writer emits an XML document, with these strings as
property values, representing the name of the type of the function.
And of course, the XML later chokes when it tries to read that XML
document, saying that the property is not valid UTF-8.
This patch addresses the issue by dropping those garbage names on the
floor, for function type names. In that context, any string that is
not made of ASCII characters is considered as being garbage, for now.
The patch, in the abixml writer, also escapes function parameters
names so that they don't contain characters that are not allowed in
XML. The abixml reader already handles the un-escaping of the names
it reads, so I think there is nothing to do there.
Ultimately, I guess I should get the unicode value of the characters
of that string, encode the string into UTF-8 and use the result as the
name for the parameter. That would mean using UTF-8 strings for
function parameter names, and, for all declarations names. But that
is too much for worfk too little gain for now. The great majority of
the binaries we are dealing with are still using ASCII for declaration
names.
The patch also introduces a new test harness that runs "abidw
--abidiff" on a bunch of input binaries. This harness runs over the
binaries that were submitted in this bug report.
* include/abg-tools-utils.h (string_is_ascii): Declare new
function ...
* src/abg-tools-utils.cc (string_is_ascii): ... and define it.
* src/abg-writer.cc (write_function_type): Escape forbidden XML
characters in function type names.
* src/abg-dwarf-reader.cc (build_function_type): If a parameter
name is not ascii, drop it on the floor.
* tests/data/test-types-stability/pr19139-DomainNeighborMapInst.o:
New test input binary.
* tests/data/test-types-stability/pr19202-libmpi_gpfs.so.5.0:
Likewise.
* tests/data/Makefile.am: Add the new binaries above to the build
system.
* tests/test-types-stability.cc: New test harness.
* tests/Makefile.am: Add the new test harness to the build system.
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.