Use of STABS debug format (original) (raw)

Mark Wielaard mjw at redhat.com
Tue Jul 31 10:41:34 PDT 2012

On Tue, Jul 31, 2012 at 09:05:02AM -0600, Daniel D. Daugherty wrote:

>Is there a reason to use STABS any more?

Yes, presuming that STABS still occupies less space than DWARF. I have not seen any proof to the contrary yet.

In theory DWARF (at least since version 2 - current version is 4, which is the new default in recent GCCs), is more space efficient than STABS. But DWARF is also more expressive, so might take up more space in the end. But DWARF information is stored in separate ELF sections and so is normally separated from the binary and put in a separate .debug file in GNU/Linux distros. I don't know if that is possible for STABS, which is stored in the symbol table, in theory it probably could if you keep symtab separate, but I don't know whether tools support that setup.

In practice all GNU/Linux distros use DWARF and newer tools (systemtap, perf, etc) don't handle STABS. GCC has defaulted to DWARF for ELF platforms since GCC 3.1 (released in 2002). You can still make GCC output STABS, but at the recent GNU Tools Cauldron it was actually suggested to just always output DWARF (and have separate tools for transforming that into other debugging formats if people still used those). GDB still supports STABS, but I don't know how well it works or is supported.

Debug info size is still an issue because we save all those artifacts for every integration job (JPRT) and for every promoted build (RE).

Of course debug info size is always an issue, but JPRT and the RE builds are not part of OpenJDK. GNU/Linux distros always build with debug info and store all their releases (with the DWARF in separate -debuginfo packages).

There are various efforts to shrink DWARF. There are several proposal for DWARF5 to make it even more efficient: http://dwarfstd.org/Issues.php And in Fedora rawhide (to become f18) we are experimenting with a DWARF compressor dwz: https://fedoraproject.org/wiki/Features/DwarfCompressor

Cheers,

Mark

More information about the hotspot-dev mailing list