mirror of
https://github.com/openharmony/third_party_elfutils.git
synced 2026-07-19 19:43:34 -04:00
fb90bf3f84b5683bbc1f234ee05008ff26250e5c
- This code is based on the following proposal:
http://www.dwarfstd.org/ShowIssue.php?issue=110722.1
- dwarf_getmacros serves either of .debug_macinfo or .debug_macro
transparently, but if the latter uses opcode 0xff, it bails out with
an error. The reason is that in .debug_macro, 0xff is a custom code
that can mean anything, while in .debug_macinfo there's fixed
semantics associated with 0xff.
- dwarf_getmacros_off is a new interface used for requesting iteration
through transparently included units.
- dwarf_macro_getparamcnt and dwarf_macro_param are new interfaces
used for requesting number of parameters of an opcode and individual
parameters. dwarf_macro_getsrcfiles is a new interface used for
requesting a file part of .debug_line unit associated with macro
unit that the opcode comes from.
- The existing interfaces dwarf_macro_opcode, dwarf_macro_param1 and
dwarf_macro_param2 remain operational for old- as well as new-style
Dwarf macro sections, if applicable.
- dwarf_getsrclines was made into a light wrapper around a worker
function that loads line unit given its offset. The worker also
caches loaded units in an offset-keyed search tree, so that we don't
end up re-reading units even though they were read in a different
domain (e.g. a macro unit request can prime cache for later CU
lookup). dwarf_macro_getsrcfiles calls the worker function under
covers.
Signed-off-by: Petr Machata <pmachata@redhat.com>
Fundamental design decision: - the sizes of external and internal types are assumed to be the same. This leaves byte ordering aside. While assuming this the code can be greatly simplified and speed increases. Since no change violating this assumption is in sight this is believed to be a worthwhile optimization. - the ABI of the backend modules is not guaranteed. Really, not guarantee whatsoever. We are enforcing this in the code. The modules and their users must match. No third-party EBL module are supported or allowed. The only reason there are separate modules is to not have the code for all architectures in all the binaries. - although the public libraries (libasm, libdw) have a stable API and are backwards ABI compatible they, and the elfutils tools, do depend on each others internals, and on internals of libelf to provide their interfaces. So they should always be upgraded in lockstep when packaging the tools and libraries separately. For one example of how to do that, see the config/elfutils.spec.
Description
Languages
C
70.8%
Shell
22.6%
C++
3.3%
Makefile
1.4%
M4
1%
Other
0.8%