Google Git
Sign in
android / platform / external / stg / 82face9
commit82face929aea9de06e945ac5707172404b999d5a[log] [tgz]
authorAleksei Vetrov <vvvvvv@google.com>Fri Jun 16 16:28:03 2023 +0100
committerMatthias Maennich <maennich@google.com>Thu Jun 22 22:16:01 2023 +0100
tree1cd335a986e731df89c756d5799b07202ea106ea
parentcdb2ff6ca3b3cf9dc60618dbc58f965be0bd071a [diff]
DWARF processor: add scoped name for functions

Functions are sometimes defined twice: the first inside the class, where it
serves as declaration of method or static field and the second outside of the
class where there is definition. The second refers to the first through
DW_AT_specification.

This change propagetes scoped name from entry with name to entry with
specification. First part is `GetNameWithContext` which extracts name and/or
specification for entry. If entry has name directly (not through
specification), it is wrapped into the current scope and stored in the
`scoped_names_` collection. `GetNameWithContext` is called for every subroutine
entry in DWARF.

Second part is using `NameWithContext` for assigning scoped name to the symbol.
It is done in `GetScopedNameForSymbol`. Either we already have scoped name,
which is immediately returned, or we have specification, which is registered as
"unresolved" in `unresolved_symbol_specifications_`.

After DWARF processing pass, all unresolved pairs "symbol-specification" are
resolved through the `scoped_names_` in `ResolveSymbolSpecifications`. Using
sort and linear pass is more efficient than resolving through
`std::unordered_map`, because "keys" (`Dwarf_Off`) are already almost sorted,
because processor goes through DWARF entries sequentially. `std::sort` is
needed to guarantee this invariant.

After this changes scope processing takes less than 100ms from 14.7s of a
kernel processing.

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

How to build the project

To build from source, you will need a few dependencies:

DebianRedHat
libelf-develfutils-devel
libxml2-devlibxml2-devel
linux-libc-devkernel-headers

Instructions are included for local and Docker builds.

Local Build

You can build as follows:

$ make

Docker Build

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.

Contributions

See CONTRIBUTING.md for details.