Petr Machata fb90bf3f84 Support .debug_macro
- 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>
2014-11-10 15:45:00 +01:00
2014-08-25 22:14:07 +02:00
2014-04-18 11:46:51 +02:00
2014-04-18 11:46:51 +02:00
2014-11-10 15:45:00 +01:00
2014-08-25 22:14:07 +02:00
2013-12-12 13:39:52 -08:00
2009-01-10 18:17:09 -08:00
2014-08-25 22:14:07 +02:00
2013-08-21 10:41:12 +02:00
2005-07-26 05:00:05 +00:00
2014-11-10 15:45:00 +01:00
2005-07-26 05:00:05 +00:00
2009-01-10 18:17:09 -08:00

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.
S
Description
暂无描述
Readme 23 MiB
Languages
C 70.8%
Shell 22.6%
C++ 3.3%
Makefile 1.4%
M4 1%
Other 0.8%