Freedom of Speech, Privacy, Science

I have not received any National Security Letter.

Please join the Electronic Frontier Foundation ( ) and the fight for your rights on the Internet.

Please join the Union of Concerned Scientists ( ) in bringing science into improving all our lives (everyone is welcome to join).

Public Domain works are a vital part of any culture and there are repeated attempts to erode the Public Domain. For more information see the Center for the Study of the Public Domain at Duke University.

HOME Software Lotus Cars DWARF Kindle Solar
graphic with lotus elise and lotus elan

DWARF Work in Progress


The current plan is to release 0.6.0 on 20 February 2023. We'll be doing a lot of testing in the next days.

The dwarf_offset_list() function was behaving badly on 32bit-pointer systems. Fixed now on github.

Now a 'cmake install' creates a libdwarf.pc file. It's probably better to use meson or configure instead though.


A new compiler is using DW_FORM_strx3 (new in DWARF5) and that revealed a serious error in libdwarf. dwarfbug DW202301-001 has details. Basically DW_FORM_strx3 and DW_FORM_addrx3 were treated as four bytes long in dwarf_util.c. This error mixed up libdwarf and could lead to a segmentation violation or other serious errors in libdwarf. So dwarfdump behaves badly too. Fixed in 0.6.0.


Thanks to Andy Postnikov for alerting us to compiler warnings due to implicitit casts (fixed Jan 15). And for pointing out that for zstd the package file name is 'libzstd' (fixed Jan 16).


Thanks to ccccmd (github issue #146) for pointing out that the dwarfdump -h text failed to mention the -f option (prints the .debug_frame section). Pushed the fix to github.


Pushed fixes to DW202212-001 dealing with newly-reported omissions in checking libelf and DWARF content..


Work has been delayed as from 4 January 2023 5PM PST to January 7, 2023 4PM PST our block near Burlingame CA had no electrical power. Equipment failure PG&E says. What they don't say is that the first 2 days of the outage they left the bad equipment in place giving us 30 volts instad of 120 volts AC -- a brownout. Yes, a couple electrical items failed as a result.

Now back to testing a fix to DW202212-001, received 28 December 2022, where a heavily fuzzed object file bypassed all existing checks and uncovered four serious omissions in Elf object file checking.


We are changing the API in 0.6.0. Fixing a 1993 library design mistake.

We are changing the API of dwarf_get_pubtypes(). Code not calling dwarf_get_pubtypes() will see no change in API.

By changing the API of dwarf_get_pubtypes() we eliminate 600 source lines in libdwarf and 2700 source lines in dwarfdump while leaving the existing capabilities intact. We also eliminate 30 functions from the API, documentation, and libdwarf code.

The change for dwarf_get_pubtypes (and the SGI sections mentioned below) has the effect of introducing a binary and source incompatibilty for those calling dwarf_get_pubtypes().

With respect to the sections involved: DWARF2 had .debug_pubnames. Dwarf3 and DWARF4 added .debug_typenames. DWARF5 has neither of these.

Four additional non-standard DWARF sections with the same format as .debug_pubnames were defined an implemented by SGI in 1993. Those never caught on (neither gcc nor clang ever emitted them).


In dwarfdump nearly all the instances of UNUSEDARG have been removed, mostly involving removing arguments from dwarfdump-internal functions (speeding up dwarfdump). A very small number will remain as a result of the way the tsearch tree-walk function interface is designed.


Release 0.5.0 issued 22 November 2022 In the release libdwarf.h DW_LIBDWARF_VERSION_MINOR is defined as 4 and DW_LIBDWARF_VERSION_MICRO is defined as 2. Those are wrong, they should be 5 and 0.


Reading DWARF DIEs is now several percent faster. The changes are library internal and do not affect the library API at all.

dwarf_get_globals() now also returns equivalent data (equivalent to that in .debug_pubnames) from the DWARF4 .debug_names section.


The definition of semantic versioning uses the term backward compatibility, as applied to a library such as libdwarf, is a bit unclear to me. The question, as of a couple days ago, is whether 0.4.3 is sufficient or whether 0.5.0 is required. Reviewing I think 0.5.0 is appropriate.

Any caller that uses libdwarf 0.4.0 or later can substitute in 0.5.0 and the caller's code will work. As you see below, the returned list from dwarf_get_globals() in 0.5.0 might be more complete (and thus more useful).

We modified dwarf_get_globals() to return all Dwarf_Global records from the DWARF5 .debug_names section as well as the DWARF4 and earlier .debug_pubnames section. In a single call.

The API of that function and the functions accessing Dwarf_Global record details are unchanged. We added a new function dwarf_global_tag_number(Dwarf_Global dg) which returns the DW_TAG of the DIE involved (for a Dwarf_Global retrieved from the .debug_pubnames section it returns zero, meaning no TAG visible there).


Libdwarf now supports a new section-compression library in addition to libz: libzstd, which has faster compression. These libraries are optional, but without the one needed for a particular section it is impossible for libdwarf to read the compressed section. Currently llvm is working on implementing this compression format, the clang/llvm option is --compress-debug-sections=zstd according to Michael Larabel.

2022-09-13 Release 0.4.2

libdwarf 0.4.2 is now released. Thanks to Herman Narkaytis for suggestions in finding and dealing with leaks in dwarfdump and libdwarf. That effort is now complete and neither fsanitize or valgrind nor CoverityScan report any issues of leakage.

Some test sets that run with only N malloc allowed to succeed for a wide range of N >= 0 were created for this effort.


Pushed the fix for a dwarfgen leak defect (via CoverityScan) today. Neither libdwarf nor dwarfdump leak now, even when malloc fails early or...whenever. That is not an absolute guarantee, but it is what tests show. Error reporting when malloc fails is much better now in a number of small ways. The fix to ossfuzz issue 51183 (libdwarf leakage of GNU debuglink and buildid sections) is included.


In rare cases dealing with reading corrupted object files or the -h command dwarfdump could leak memory (not large amounts). And libdwarf could leak a one or two 40 byte records. These issues appear to have been fixed though testing of this is incomplete. So work is still going on, But all the usual tests pass.


Added a github action building and checking libdwarf in FreeBSD. Thanks to Herman Narkaytis helping make this happen.


A tentative release date for 0.4.2 has been set: 15 September 2022.


As of Today Work In Progress is a separate html page making it a little closer to a blog :-)

Reminder: the libdwarf documentation has been entirely rewritten using doxygen as of February 2022. It has contents tables and links to tie things together, so it's much easier to read and find things than previously. See libdwarf-code/doc/libdwarf.pdf in release 0.4.1 or in the github source. An on-line html version is

Vulnerabilities DW202207-001 and DW202208-001 were reported and fixed. Their fuzzed (corrupted) object files could possibly crash libdwarf. A big thank you to David Korczynski and Han Zheng for reporting the vulnerabilities and providing concise test cases. (28 August 2022)

Some fixes to the test build scripts (configure,meson,cmake) enable 'make check' (or equivalent for all three supported build systems) to work properly in Linux,MacOS, and now MinGW64 msys2 (Windows).

Warnings reported by Windows Visual Studio C compiler and by CoverityScan have been fixed. One of the warnings even identified a bug in dwarf_tsearchhash.c, though it was not a bug that affected any libdwarf API calls. Thanks to Vincent Torri for reporting Visual Studio's warnings. (28 August 2022)

2022-06-25 Release 0.4.1

Released library version v0.4.1. Includes fix for DW202206-001, a bug in dwarf_form.c when reading a carefully corrupted object file. (25 June 2022)


Thanks to several people who have provided improvements to and detailed bug reports on libdwarf/dwarfdump for release 0.4.1. Heiko Becker, Ilfak Guilfanov, klueke, MaqiGod, pedronavf, Casper Sun, and major contributor Vincent Torri.

Casper Sun reported, 26 May 2022, a previously unknown vulnerability in libdwarf that can lead to a segmentation violation reading a carefully corrupted DWARF .debug_pubnames (or .debug_pubtypes) section, and provided such a corrupted object file for testing. DW202205-001 (Fixed 29 May 2022)


Now doing builds on MacOS through github. See for details. (April 17,2022)

2022-03-04 Release 0.4.0

The latest release is 0.4.0 released 2022-04-12. dwarf_xu_header_free() renamed to dwarf_dealloc_xu_header(). dwarf_gdbindex_free() renamed to dwarf_dealloc_gdbindex(). dwarf_loc_head_c_dealloc renamed to dwarf_dealloc_loc_head_c(). The unused Dwarf_Error argument to dwarf_return_empty_pubnames() has been removed. This completes the argument changes and function renaming that needed to be done. (March 4, 2022)

2022-03-04 small fix

It's come to our attention that building on Windows with cmake does not get -DLIBDWARF_BUILD defined. In src/lib/libdwarf/CMakeLists.txt, around line 77 try:

-        target_compile_options(${target} PRIVATE ${DW_FWALL})
+    target_compile_options(${target} PRIVATE -DLIBDWARF_BUILD
+            ${DW_FWALL})

(February 25, 2022)

2022-02-25 Rewrite of libdwarf.pdf complete

libdwarf.pdf has been completely rewritten. A much easier to work with libdwarf.pdf is in release 0.3.4, created with doxygen. That content is available on the web as html. (25 February 2022)


We will be working on 0.4.0 soonish. Release 0.4.0 will have four function spelling changes and one argument delete, all to correct old mistakes. (25 February 2022)

2022-02-25 First meson builds

Thanks to Vincent Torri builds of much of the package can be done with meson. A particular configure build takes 48 seconds by the wall clock, but a meson build takes 3 seconds with the same build machine and C compiler. The meson commands are not yet well documented documented in (cmake and configure will be continue to be supported for the foreseeable future.) Thanks to Vasilly Prokopyev for noticing the PE reader code was doing one sanity check incorrectly. (20 February 2022)

2022-02-25 Simplification in #include setup

Thanks to Vincent Torri for major clarification and rearrangement of the #include entries in dwarfdump. (28 January 2022)