![]() |
DWARF Debugging Standard Wiki |
---|
It doesn’t need one.
The table is based on creating row entries, conceptually a row entry for every pc value in the executable text. All the booleans in the line table, such as is_stmt, basic_block, end_sequence, prologue_end, and epilogue_begin are reset by the creation of a new row in the table (see the individual opcodes that create table rows to see this). Each row in the line table is defined by a sequence of one or more line table opcodes and the opcodes precisely define the value of every column of every row.
In DWARF3, DW_FORM_ref_addr is clearly defined as being an offset into the .debug_info section so the reference value is the size of an offset. In DWARF2 DW_FORM_ref_addr was (confusingly) defined as being the size of an address on the target machine. The DWARF2 definition never made any sense and was a mistake in the DWARF2 specification: the field DW_FORM_ref_addr defines is an offset, not an address.
Whether producing DWARF2 or DWARF3, please use the DWARF3 definition of DW_FORM_ref_addr.
The goal is maximum density.
The ‘instructions’, the opcodes, take as little space as possible yet faithfully represent much detail about the source lines (and how they relate to the object code). Most opcodes are special opcodes. These encode (in a single byte) both the opcode and a machine address and (effectively) a range of source lines. Standard opcodes take a bit more space and represent special information. Extended opcodes take even more space and encode a variable-length instruction.
This design is effectively a fourth-generation line table.
All generations being designed by one person (with help of course, and over several years). Earlier generations were originally used by MIPS COFF (generation 1) and Borland (generations 2 and 3?).
There is lots of information in DWARF and no tool presently does precisely this. Yet there are tools that make it fairly straightforward to get this information. Because C++ class information is complicated by its nature this is not a simple task. All the open-source codes mentioned below have license terms, be sure to understand and obey those terms if you use any code and applications mentioned.
readelf.
Readelf is a GNU binutils application that can do many things, but one of those things is print DWARF DIEs and attributes as text. A script or program could read this text and find and interpret the desired information. If (instead of just running readelf) you borrow code from readelf you must obey readelf’s license terms, of course.
gdb.
The GNU gdb debugger reads DWARF directly from object files. That code could be adapted. Or gdb could be used itself as a ‘backend’. See the gdb MI interface documentation for examples of one way to use gdb as a ‘backend’.
dwarfdump.
Dwarfdump is an application (packaged with libdwarf) that can print DWARF DIEs and attributes as text. A script or program could read this text and find and interpret the desired information.
libdwarf
Libdwarf is a C library API for reading dwarf information (packaged with dwarfdump).
In addition to pretty-printing DWARF it can also be used to query the debug information, print debug info quality metrics, and verify the structural integrity of DWARF debug information. Llvm-dwarfdump is part of the LLVM project.
This question is really about operating systems and debuggers and compilers, not so much about DWARF.
A short answer is that it is possible to access global variables in a running program from some debuggers running on some operating systems against applications compiled by some compilers. Whether one can find object information on disk (such as the DWARF information) for a running application also depends on the operating system. In most situations it makes no sense to think about accessing local variables as it’s hard to tell at any point when any given local variable is still live: by the time one has finally determined a variable is live it may have vanished or moved.
dwarfstd.org is supported by Sourceware. Contributions are welcome.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2007-2022 by DWARF Standards Committee. |