Use of STABS debug format

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