commit | c54186c03c685557ea57ce8068e4658f63457c20 | [log] [tgz] |
---|---|---|
author | Giuliano Procida <gprocida@google.com> | Thu Aug 25 16:41:39 2022 +0100 |
committer | Giuliano Procida <gprocida@google.com> | Thu Aug 25 16:42:52 2022 +0100 |
tree | 781074c04a9c4be6e92fa99de26f680606d2a164 | |
parent | 0c50d97f07ecfc7eb2293715e67fb1855b660b17 [diff] | |
parent | f1f031e5d26b2ed803156e97f8e7819bd732f66f [diff] |
Merge branch 'upstream-master' into 'master' * aosp/upstream-master: reporting: include symbol kind in symbol descriptions reporting: tweak ELF symbol type descriptions post-processing: relax symbol description regexes scc_test.cc: remove special printing of SCCs rename all PrintSmth functions to SmthToString ELF loader: fix symbol visibility attribute fetch print version information in `ElfSymbol` description store symbol information in the separate `VersionInfo` structure Bug: 243637100 Change-Id: I69509775fee2ecf8fe54477bb805a4734f287e32 Signed-off-by: Giuliano Procida <gprocida@google.com>
The STG (symbol-type graph) is an ABI representation and this project contains tools for the creation and comparison of such representations. At present parsers exist for libabigail's ABI XML (C types only) and BTF. The ABI diff tool, stgdiff, supports multiple reporting options.
This software currently depends on libxml2 for XML parsing, on libelf to find .BTF sections and on Linux UAPI headers for BTF types.
To build from source, you will need a few dependencies:
Debian | RedHat |
---|---|
libelf-dev | elfutils-devel |
libxml2-dev | libxml2-devel |
linux-libc-dev | kernel-headers |
Instructions are included for local and Docker builds.
You can build as follows:
$ make
A Dockerfile is provided to build a container with libabigail to easily compile the STG tools:
$ docker build -t stg .
And then enter the container:
$ docker run -it stg
If you want to bind your development code to the container:
$ docker run -it $PWD:/src -it stg
The source code is added to /src
, so when your code is bound you can edit on your host and re-compile in the container.
Note that the Dockerfile can provide a development environment (non multi-stage build with the source code) or a production image (a multi-stage build with only the final binary). By default we provide the first, and you can uncomment the final lines of the file for the latter.
See CONTRIBUTING.md for details.