MiniDebugInfo support in libunwind

This page should serve as an external memory for me and probably doesn't contain anything interesting for anyone else.

Email from Alex

Libunwind currently does not support separate debug info, which is a
barrier to implementing the new model of minidebuginfo (which is
essentially just a compressed separate debuginfo file in a section).
This has two parts that need to be implemented:
 * Find the separate debug info files (mostly some filename magic)
 * Handle the possible offset from the main binary to the separate
   debuginfo file due to prelink.

The second one is the more complex one, but all the behaviour can be
lifted from gdb.

With that in place you should be able to just lift the runtime
decompression code in my gdb patch to easily add minidebuginfo support.

Initial observations

  • There appears to be some filename magic going on in src/dwarf/Gfind_proc_info-lsb.c. It seems that libunwind supports external debuginfo files when compiled with --enable-debug-frame, although looking up the debuginfo file via build id is not supported.
  • The code that looks up procedure names seems to be independent of the code that loads the unwind tables. The .get_proc_name AS accessor mostly sets up an ELF image and then calls one of the functions in src/elfxx.c. NOTE: check that libunwind compiled with --enable-debug-frame fails to report the correct symbol

Implementation questions

How to decompress?

Current symbol lookup code works on ELF image loaded in memory (mmaped). How should we go about working on XZ-compressed files?

  • Transparently mmap them into memory.
    • AFAIK impossible.
  • Decompress them to a temporary file (i.e. onto disk) and mmap the file.
    • The file may be large and it's probably better to waste disk space temporarily than memory.
    • Need to reliably delete it afterwards.
    • The library never creates any files and it seems to be weird.
    • Write, mmap, delete?
  • Decompress them directly to the memory.
    • The file may be large.
    • current favourite (use mmaped memory)
  • Rewrite the code to access the ELF image in a different way.
    • Requires substantially more effort.
    • Risk of breaking the functionality and programs depending on it.


  • Aren't the library dependencies (ldd unacceptable?
  • Where to put the code?



liblzma has no API documentation, but README says:

The liblzma API headers include short docs about each function and data type as Doxygen tags. These docs should be quite OK as a quick reference.

I have planned to write a bunch of very well documented example programs, which (due to comments) should work as a tutorial to various features of liblzma. No such example programs have been written yet.

For now, if you have never used liblzma, libbzip2, or zlib, I recommend learning the basics of the zlib API. Once you know that, it should be easier to learn liblzma.