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.
- 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_nameAS 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-framefails to report the correct symbol
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 libunwind.so) unacceptable?
- Where to put the code?
- Fedora feature page http://fedoraproject.org/wiki/Features/MiniDebugInfo
- RPM implementation
- GDB implementation
- fedora-devel thread 1
- fedora-devel thread 2
- Site hosting DWARF debugging format standard documents http://dwarfstd.org/
- Blog post about stack unwinding http://gnu.wildebeest.org/blog/mjw/2007/08/23/stack-unwinding/
liblzma has no API documentation, but
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.