DWARF processor: always pass short type name to type definition filter check

The name is currently only used for diagnostics and for checking for
rare built-in types when the declaration file attribute is missing.

Contrary to previous expectations, the rare built-in types can be in the
`std` namespace. The check looks for `__` as a prefix to determine
whether a type is built in.

PiperOrigin-RevId: 605634489
Change-Id: I05579facc10fbb8bd01ab9a90ed6c6a0858c97b4
1 file changed
tree: 4a34ceb89e4ecce73f3992d2188e9a41ddcdeb41
  1. cmake/
  2. doc/
  3. fuzz/
  4. test_cases/
  5. testdata/
  6. abigail_reader.cc
  7. abigail_reader.h
  8. abigail_reader_test.cc
  9. btf_reader.cc
  10. btf_reader.h
  11. catch.cc
  12. CMakeLists.txt
  13. comparison.cc
  14. comparison.h
  15. CONTRIBUTING.md
  16. deduplication.cc
  17. deduplication.h
  18. Dockerfile
  19. dwarf_processor.cc
  20. dwarf_processor.h
  21. dwarf_wrappers.cc
  22. dwarf_wrappers.h
  23. elf_loader.cc
  24. elf_loader.h
  25. elf_reader.cc
  26. elf_reader.h
  27. elf_reader_test.cc
  28. equality.h
  29. equality_cache.h
  30. error.h
  31. error_test.cc
  32. fidelity.cc
  33. fidelity.h
  34. file_descriptor.cc
  35. file_descriptor.h
  36. file_descriptor_test.cc
  37. filter.cc
  38. filter.h
  39. filter_test.cc
  40. fingerprint.cc
  41. fingerprint.h
  42. graph.cc
  43. graph.h
  44. hashing.h
  45. input.cc
  46. input.h
  47. LICENSE
  48. METADATA
  49. MODULE_LICENSE_LLVM
  50. naming.cc
  51. naming.h
  52. order.h
  53. order_test.cc
  54. OWNERS
  55. post_processing.cc
  56. post_processing.h
  57. proto_reader.cc
  58. proto_reader.h
  59. proto_writer.cc
  60. proto_writer.h
  61. reader_options.h
  62. README.md
  63. reporting.cc
  64. reporting.h
  65. reporting_test.cc
  66. runtime.cc
  67. runtime.h
  68. runtime_test.cc
  69. scc.h
  70. scc_test.cc
  71. scope.h
  72. stable_hash.cc
  73. stable_hash.h
  74. stg.cc
  75. stg.proto
  76. stgdiff.cc
  77. stgdiff_test.cc
  78. substitution.h
  79. type_normalisation.cc
  80. type_normalisation.h
  81. type_resolution.cc
  82. type_resolution.h
  83. unification.cc
  84. unification.h
README.md

Symbol-Type Graph (STG)

The STG (symbol-type graph) is an ABI representation and this project contains tools for the creation and comparison of such representations.

The ABI extraction tool, stg, emits a native ABI format. Parsers exist for libabigail's XML format, BTF and ELF / DWARF.

The ABI diff tool, stgdiff, supports multiple reporting options.

STG has a versioned native file format. Older formats can be read and rewritten as the latest.

NOTE: STG is under active developement. Tool arguments and behaviour are subject to change.

Getting STG

Distributions

We intend to package STG for major distributions. Currently we have packages as follows:

DistributionPackage
Arch Linux (AUR)stg-git

Source Code

This source code is available at https://android.googlesource.com/platform/external/stg/.

Building from Source

Instructions are included for local and Docker builds.

Dependencies

STG is written in C++20. It is known to compile with GCC 11, Clang 15 or later versions.

DependencyDebianRedHat
buildcmakecmake
ELF, BTFlibelf-develfutils-devel
DWARFlibdw-develfutils-devel
XMLlibxml2-devlibxml2-devel
BTFlinux-libc-devkernel-headers
native formatlibprotobuf-devprotobuf-devel
native formatprotobuf-compilerprotobuf-compiler
allocator[^1]libjemalloc-devjemalloc-devel
catch2[^2]catch2catch2-devel

[^1]: jemalloc is optional, but will likely improve performance. [^2]: catch2 is optional, but required to build the test suite.

Local Build

Build STG using CMake as follows:

$ mkdir build && cd build
$ cmake ..
$ cmake --build . --parallel

Run the STG unit test suite:

$ ctest

Docker Build

A Dockerfile is provided to build a container with the STG tools:

$ docker build -t stg .

And then enter the container:

$ docker run -it stg

Note that the Dockerfile provides only a production image. To use Docker as a development environment, you can comment out everything after the line # second stage.

After that you may 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.

Contributions

See CONTRIBUTING.md for details.

Contact Information

Please send feedback, questions and bug reports to kernel-team@android.com.