|Censorship, Freedom of Speech, Privacy|
|See my censorship/privacy/freedom web page with its links on US government efforts to control the Internet. Note: I have not received any National Security Letter.|
|Please join the Electronic Frontier Foundation (EFF.org) to join the fight for your rights on the Internet.|
|HOME||Software||Palm||DWARF||Lotus Cars||RPM Building||eeepc||kindle|
David A's DWARF Page
libdwarf and dwarfdump are Free Software, but if you find either useful you can support their development via the Paypal button:
The distribution consists of C and C++ source code that you compile with your C/C++ compiler (documentation is included).
The DWARF Debugging Information Format is of interest to programmers working on compilers and debuggers (and anyone interested in reading or writing DWARF information). It was developed by a committee (known as the PLSIG at the time) starting around 1991. Starting around 1991 SGI developed the libdwarf and dwarfdump tools for internal use and as part of SGI IRIX developer tools. Since that time dwarfdump and libdwarf have been shipped (as an executable and archive respectively, not source) with every release of the SGI MIPS/IRIX C compiler. In 1994 (I think the correct year) SGI agreed (at my request) to open-source libdwarf (and in 1999 to open-source dwarfdump) so anyone could use them.
License terms are mostly GPL (version 2) or LGPL (version 2.1). The details are discussed in the license page.
DWARF specifications and the dwarf email forums are at http://www.dwarfstd.org. Sign up for the email discussion list there.
Email about libdwarf and dwarfdump may be sent to libdwarf-list -at- earthlink -dot- net (replace -at- and -dot- with the normal single characters to form the email address).[top]
Support for groups of CUs inside large sections ( .dwp object file) is still missing and is the next task. There is not much use of Elf Section Groups AFAICT (as a practical matter) so I'm ignoring Section Groups for now -- is anyone using this Elf feature with DWARF currently?
The dwarf_producer_init() function interface changed so existing calls will fail at caller compile time. And the producer callback function name changed too. This returns the code to a single producer-init function and one with an easier to understand option list. It also results in the elimination of very messy producer configure-time options and code #ifdefs relating to relocation generation in favor of simple run-time choices. Code calling the consumer (reader) interfaces is not affected.
A correspondent reports that a Go language implementation emitted DW_FORM_ref_addr according to DWARF V2 for the case of 64 bit addresses with 32 bit DWARF offsets. Libdwarf was assuming no one was going to do that in the odd way DWARF2 documented. Now libdwarf follows the standard (as it really should have all along). Thanks to Arnaud Diederen for pointing out this blunder and for providing a tiny Go test source.[top]
Because tsearch() itself is not universally available (and even when tsearch() is available tdestroy() is sometimes not available) I implemented some tree algorithms using the standard tsearch interface definitions.
The basic four tsearch Standard interface declarations are quite old, traditional, incompletely documented, hard to use, and not at all what anyone would design as an interface today. But these four functions are declared in the Posix/SingleUnixSpecification standard.
The algorithms implemented are binary tree, binary tree with Eppinger delete, balanced binary tree, red black tree, and even a hashing version). The function interfaces implemented include tsearch(), tdelete(), tdestroy(), tfind(), and twalk(). All these are in a directory named tsearch beginning with the 20140131 release of libdwarf. The test data for tsearch testing was moved to the regressiontests git repository as of the 20140208 release (to save space in the release source tar file).
To avoid conflicts with standard library versions all the function names are prefixed with dwarf_. Libdwarf and dwarfdump now use the new tsearch.
I ran all the distribution's source code through the checker called STACK from mit.edu. It checks C/C++ source for many sorts of errors. For example, it finds undefined-effect C code. Code optimizers increasingly delete code with undefined-effect so what used to work in your code can stop working. STACK depends on building llvm and clang with specific options and all this is nicely defined on the STACK web page.
I highly recommend this checker for any code you ship.
With Ubuntu 13.10 I found it easy to run C code through the tests. With C++ there were issues with missing gcc headers which required an annoying workaround. I fixed the two errors STACK found, both of which were in libwarf's producer code. The errors involved using a pointer before testing it for NULL. The tests involved would only have effect if callers passed in invalid arguments and meant callers could coredump instead of seeing an error return.
January 31, 2013: Announcing this incompatible change!
In June 2013 there will be an incompatible change to libdwarf.h which will mean those compiling against the producer code in libdwarf will encounter an error. The Callback function prototype will add 'const' to a char * argument in the Callback functions whose types are named below. This is not a binary incompatibility it is a source compile time incompatibility.
Generally the only people affected are those compiling a compiler that uses libdwarf to generate DWARF2. The function prototypes in libdwarf.h are named Dwarf_Callback_Func_c, Dwarf_Callback_Func_b, and Dwarf_Callback_Func.
It will not affect folks linking against libdwarf but not recompiling the code calling libdwarf.
The fix is simple: add 'const' to the char* argument to your libdwarf callback prototypes and implementation.
This change will let us eliminate several compiler warning messages from the build of libdwarf. It will not affect folks calling only the consumer interfaces of libdwarf. Only those who coded callback functions using the libdwarf producer callbacks are affected.
All libdwarf distributions contain C source plus the DWARF2 specification plus libdwarf specifications. Implementors often extend DWARF by adding new attributes and other things. Those that we are aware of are defined in dwarf.h which is provided here for reference. If you have corrections or additions, please let me know! The file is in every distribution of libdwarf.
Beginning 19 March 2011 libdwarf source code is available
via anonymous access with git.
The git source code is the most recent: it may have
features or fixes not in a tar.gz release, but if so the
features or fixes are not needed by most people.
Top-of-trunk code in the git repository has been fully tested.
Beginning 15 October 2012, the repository is under Sourceforge's new setup so the anonymous clone commands have changed.
"git clone git://git.code.sf.net/p/libdwarf/code"
initializes a git repository in the local directory it will create named "code" and populates it with the most up to date libdwarf source.
The regression tests (which you really don't need or want) are available
"git clone git://git.code.sf.net/p/libdwarf/regressiontests" .
A small indent-checking tool in case you make changes and want
to preserve proper libdwarf indentation is in
"git clone git://git.code.sf.net/p/dicheck-da/code"
but since this one also creates a directory named "code" do this command in a different directory from the one used to hold libdwarf "code".
The libdwarf build process involves a simple traditional approach (at least for personal use, people generating binary releases or a corporate library will have their own internal requirements to consider). In the base directory of the source distribution (either expanded from a tar.gz or from git) do the following:
./configure make dd
If all goes well, this will build libdwarf and dwarfdump.
If you want to try building all the executables, do
which will build libdwarf, dwarfdump, dwarfdump2, dwarfgen, and dwarfexample in a minute or two. You don't really need dwarfgen or dwarfexample, so if the compile fails in one of those don't worry about it. If libdwarf and dwarfdump complete their build you have most of the functionality you need. dwarfdump (written in C) and dwarfdump2 (written in C++) do the same job, they let you dump out, in readable form, the DWARF2, DWARF3, or DWARF4 data from an object file.
There are some prerequisites you must have installed on your build machine:
C compiler (conformant with, at mininum, the 1989 C standard) C++ compiler (for dwarfdump2) libelf (for libdwarf and dwarfdump and dwarfdump2).
None of this understands the object files in Apple MacOSX. I don't have time to provide such, and no one else has proposed contributing such support. Contact the libdwarf-list email address before attempting to contribute any code.
None of this understands the object files in Microsoft Windows. A few people have made libdwarf and dwarfdump work on Windows, but none have contributed any support code. Contact the libdwarf-list email address before attempting to contribute any code. Note that libdwarf has specific design features that enable reading of non-Elf object files without very much difficulty, but you will have to write your own code to read those files and will need to do a special build of libdwarf that does not use Elf related headers (which should be relatively easy). Use of one of the POSIX-like environments like mingw or cygwin or the like will likely ease your way considerably.
The regression test build process involves rather more work, and few will want to bother with it. There is no tar.gz available, you have to use git. In the base directory of the regressiontests distribution do the following (if the base of the libdwarf source tree is at ../code this should work, but if not see the regressiontests/README.txt file):
Rather than keeping known-good output in the regression-tests, we keep a dwarfdump.O (O for Old) and dwarfdump2.O and compare output against the new dwarfdump and dwarfdump2. We do it this way as the test output is much too large to save.
To run the dwarfextract test successfully, bfd.h needs to be installed in a standard place, so install binutils-dev (or the equivalent for your release) to get bfd.h.
On a modern machine running directly on the host the tests should run in about two hours and the final message should say PASS (the tests run 3 sets of similar tests, set each taking about 40 minutes, each will print PASS as it ends if successful --- and FAIL if not successful). Unless the components in the libdwarf source build correctly the tests cannot pass. Unless you are running Ubuntu GNU/Linux or FreeBSD 9.1 you may have more work to do to run the tests, partly because the tests depend on having a known-good version of dwarfdump and dwarfdump2 in the distribution.
If the Ubuntu or FreeBSD objects in the distribution won't run in your test environment you could build dwarfdump.O and dwarfdump2.O to run tests:
|filename, download-link||Bytes||Reason for release|
The reader now can get the content of .gdbindex and .debug_cu_index and .debug_tu_index sections and dwarfdump -I can print them. Support is incomplete for the cu,tu sections: They exist in a .dwp object (GNU Debug Fission, to be in DWARF5) which is not yet properly handled.
sha512sum (remove spaces following colon): 7d256cc7c37e44301ca963f042fef83c5491cb2a79a137 70a03bde0b0f51fafbb5a37c54570c7d9a8f4bb0b18ad1 4b0af172b779163a9a3f2b2574a7c2997b42
Source incompatibility for users of producer code: dwarf_producer_init() now has a new interface and a sensible way to select the output ABI/ISA for relocation numbers. Part of preparation to emit DWARF3,4,5. The reader code now handles DebugFission, called Split Dwarf objects in the draft DWARF5 standard.
sha512sum (remove spaces following colon): ccf8180b69cdb47902564dda1fca52d15c10239ce6bb8c c9f5af5a67d37f888811572e314414372bfbc2b640c1fff 7cf87542f782f8390f733d884a24d9a16fb
Libdwarf now follows the DWARF2 standard properly in reading DW_FORM_ref_addr. The original DWARF2 standard is on dwarfstd.org so it's gone from the libdwarf source.
sha512sum (remove spaces following colon): 7ecd27b40418fd98bb24ee59b9779efe30dca26384b4a36f5 a1b0a99805f4d8ff281b2e3d4470fb8e8da28045c34bf6b53 fdf85e9dfc5fa76c0eac8462ae8467
Fixed a bug in dwarfdump Makefile.in so parallel make works reliably. Removed remaining trailing-whitespace. Moved tsearch testcases over to the libdwarf regressiontests repository as the tests seemed too large to keep in the source.
sha512sum (remove spaces following colon): d8ba3eeaf36d98a1ee26397208fff1658a2b7a41c 25d3742a81617c74d6359aeff08bb6221f99b9937 9030575578e11cd66be1d906a5832a6edd362229ce2e7e
Radically simplifies libdwarf allocation code. Adds GNU-specific DW_FORM codes so recent gcc objects can be read usefully. Adds tseach implementations (see the tsearch directory). Removes trailing whitespace (it appeared all over). Adds new functions to libdwarf for new DWARF reference types. The tsearch test cases have bloated this source release, but in future those test cases won't be in the tar file (instead they are in the libdwarf regressiontests repository on sourceforge).
sha512sum (remove spaces following colon): d41ebe4e7b76ad91f93b17e33da878fb0a35d7a35 32d641108b217bf93bcd9f10c1d52f0dd5f2ece08 3152d8dafe637ae343633f894122cbb77825b7a3350ed2
Added AARCH64 relocation support. Fixed some simple compiler warnings.
sha512sum (remove spaces following colon): f9d25cfd6c6b15bebf6cd63c7014ecf4123798fce637c 0da103008758d6a9d5705c3797216a8d1ab3e210c4235 f199ab19d7ed0bf6c3582f49eacba1629c5cc0
Now with a simplified build (see README) and with checks for most compiler errors in producing DW_AT_sibling attributes. Verified on Ubuntu 12.10 and FreeBSD 9.1.
sha512sum (remove spaces following colon): 1cb272f80745a789d592d57e6a64b1b4ec6e1b646653 da2f19c2e2d803b8e90b52f5c69597360bf1703b1c25 7844c53c3f43a80cd9f45a2adb314ad2511c19e9
A mistake in handling DW_OP_GNU_const_type could lead to a libdwarf coredump at times, and even when it appeared to work the value printed was wrong. Thanks to Tom Hughes and Andrew Bernat for pointing out the DW_OP_GNU_const_type problem. This release has libdwarf interfaces compatible with releases before 20130125. Compared to 20130125 this restores the libdwarf.h interface Dwarf_Loc structure and changes the way the lr_number2 member is used for the new location expression operator DW_OP_GNU_const_type.
sha512sum (remove spaces following colon): c9911ce0b9725400ec1a70e809e185b122095c534f05687 ea0be16a0e9bfe3b8128e353834c43b5fe80e1b149b11 f113fcce53c57bad0a12b3b091dd0e31d043
For information on previous releases, see the older release list
Every release of libdwarf/dwarfdump is tested with many options and option-combinations. There is no real reason libdwarf/dwarfdump users should need to redo this testing work. However, if you do wish to try running the regression tests, you will find them in git in sourceforge via anonymous access "git clone git://git.code.sf.net/p/libdwarf/regressiontests". See the file README.txt in the base directory of the tests for an overview of the test process. We do not provide a tar file of the regression tests. The regression tests are updated with every libdwarf release.
Additional tests (simple object files or shared-objects or executables) are accepted here should you wish to submit such, but the goal is to add tests that represent previously-untested aspects of DWARF/libdwarf, not to duplicate existing tests. Smallish object files are preferred. No source need be provided. The submitter has to be sure, and state, that releasing the objects here is appropriate.
Nothing in libdwarf looks at very many sections of an Elf file: the other section contents can be zeroed out without affecting the object use for testing libdwarf (see the directory named 'zero' in the testing distribution for a convenient byte-zeroing helper application in C++ source). Sections like .text and .data (and closely related sections) are of no value for testing libdwarf. It may be that otherwise-proprietary objects can be released for use in this test suite once the instruction and data sections are zeroed out.[top]