Use of STABS debug format

Daniel D. Daugherty daniel.daugherty at
Tue Jul 31 08:05:02 PDT 2012


There are a number of issues/questions in this e-mail and
I'll see what I can do to address/reply to all of them.

On 7/30/12 5:42 PM, Andrew Hughes wrote:
> Hi all,
> It seems that following:
> 7071904: 4/4 HotSpot: Full Debug Symbols
> a number of architectures on Linux (including x86) have started building with the
> STABS debug format rather than DWARF.

Yes, the fix for 7071904 enabled building with STABS debug
format for many configs. However, the "rather than DWARF"
part of the above confuses me slightly. Do you mean:

     These configs used to build with DWARF before and
     now build with STABS.

Or do you mean:

     These configs now build with debug info, but DWARF
     should have been used instead of STABS.

I suspect you mean the second interpretation.

> This is presumably due to the addition of this block:
> +ifneq ($(OBJCOPY),)
> + FASTDEBUG_CFLAGS/ia64 = -g
> + FASTDEBUG_CFLAGS/amd64 = -g
> + FASTDEBUG_CFLAGS += -gstabs
> + endif
> +
> + OPT_CFLAGS/ia64 = -g
> + OPT_CFLAGS/amd64 = -g
> + OPT_CFLAGS/arm = -g
> + OPT_CFLAGS/ppc = -g
> + ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
> + OPT_CFLAGS += -gstabs
> + endif
> +endif
> +
> Prior to this, I don't believe product builds had debug information by default.

Correct. On Linux, neither product builds nor fastdebug builds
had debug info enabled.

> You'd have to set DEBUG_BINARIES (something we do).

I believe that DEBUG_BINARIES still works as an override. At least
that's what my testing so very long ago indicated.

> 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.

> For our part, it's causing bugs such as:

Based on a quick read of that bug, the problem there seems to be
missing debug info. If your debug info is only there for 3 out
of 500+ CUs, then something is wrong with the build process.

> This statement:
> # Use the stabs format for debugging information (this is the default
> # on gcc-2.91). It's good enough, has all the information about line
> # numbers and local variables, and is only about 16M.
> # Change this back to "-g" if you want the most expressive format.
> seems dated (Fedora, for example, is on gcc 4.7) and the size argument
> seems redundant, given debug information is now stripped and stored in
> separate compressed files by default.

The comment might be dated if DWARF is no longer much bigger than STABS.
However, I have not seen any proof to the contrary yet.

I'm confused by "size argument seems redundant". Why does the stripping
of debug info and storing it in a separate compressed file make the size
argument "redundant"?

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

> Is there any reason to retain the use of STABS on x86 and SPARC, the only supported
> architectures not opted out above as far as I can tell?

The only reason to use STABS is that it is smaller than DWARF.

> Note that our concern is the Linux makefile and we're more than happy to leave STABS
> in place on Solaris and *BSD, if necessary, as we don't build there :-)

I don't have a problem with using STABS on Solaris and using something
else on Linux.

Here's the relevant part of the changeset in question with a bit
more context:

       211 # Debug flags
       213 # Use the stabs format for debugging information (this is the 
       214 # on gcc-2.91). It's good enough, has all the information 
about line
       215 # numbers and local variables, and is only about 16M.
       216 # Change this back to "-g" if you want the most expressive 
       217 # (warning: that could easily inflate to 150M!)
       218 # Note: The Itanium gcc compiler crashes when using -gstabs.
       219 DEBUG_CFLAGS/ia64  = -g
       220 DEBUG_CFLAGS/amd64 = -g
       221 DEBUG_CFLAGS/arm   = -g
       222 DEBUG_CFLAGS/ppc   = -g
       224 ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),)
       225 DEBUG_CFLAGS += -gstabs
       226 endif
       228 ifneq ($(OBJCOPY),)
       229   FASTDEBUG_CFLAGS/ia64  = -g
       230   FASTDEBUG_CFLAGS/amd64 = -g
       231   FASTDEBUG_CFLAGS/arm   = -g
       232   FASTDEBUG_CFLAGS/ppc   = -g
       234   ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),)
       235     FASTDEBUG_CFLAGS += -gstabs
       236   endif
       238   OPT_CFLAGS/ia64  = -g
       239   OPT_CFLAGS/amd64 = -g
       240   OPT_CFLAGS/arm   = -g
       241   OPT_CFLAGS/ppc   = -g
       243   ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
       244     OPT_CFLAGS += -gstabs
       245   endif
       246 endif
       248 # DEBUG_BINARIES overrides everything, use full -g debug 
       249 ifeq ($(DEBUG_BINARIES), true)
       250   DEBUG_CFLAGS = -g
       251   CFLAGS += $(DEBUG_CFLAGS)
       252 endif

I added the block from lines 228 -> 246. Note that I modeled the
FASTDEBUG_* and OPT_* settings on the existing DEBUG_* settings.
In other words, if a particular arch-config used DWARF in the
DEBUG_* flags, then I preserved that choice in the new FASTDEBUG_*
and OPT_* flags. If a particular arch-config defaulted to STABS,
then I preserved that also.

Things to note:

- FASTDEBUG_* didn't have ANY debug flags set and now it does.
   I tracked that back during the FDS project to a particular
   bug fix, but I don't remember the details. I'm pretty sure
   it was a reaction to a size related issue.
- The DEBUG_BINARIES override only resets the DEBUG_CFLAGS value
   to "-g" and doesn't touch FASTDEBUG_CFLAGS or OPT_CFLAGS.
   However, it does add '-g' to CFLAGS so the flag does get into
   the other build configs, but I'm not sure of option ordering.

It would be easy to switch the X86 arch-config from defaulting
to STABS to specifically using DWARF, but I would need to see
some size delta information and a good reason to make the change.


More information about the hotspot-dev mailing list