Use of STABS debug format
ahughes at redhat.com
Tue Jul 31 06:26:53 PDT 2012
----- Original Message -----
> I would love for stabs to go away for linux 32 bit. I think there
> a size issue once with that platform and was filling up our disk. I
> think I changed this recently and noticed that the issue is gone.
That's what's noted in the comments. However, there's also a regression here:
1. Prior to 7071904, '-gstabs' was only added for debug builds and fastdebug/opt
builds did not have debugging information.
2. After 7071904, '-gstabs' is added to all builds except on arm, ppc, x86_64 and
This conflicts with the DEBUG_BINARIES option we use for building that adds '-g' to
all builds. It means that, with the change in 7071904, our builds now get '-g -gstabs'
on x86, whereas before they just got '-g'.
Maybe the following would work without affecting your builds:
@@ -274,6 +274,8 @@
# DEBUG_BINARIES overrides everything, use full -g debug information
ifeq ($(DEBUG_BINARIES), true)
DEBUG_CFLAGS = -g
+ OPT_CFLAGS = -g
+ FASTDEBUG_CFLAGS = -g
CFLAGS += $(DEBUG_CFLAGS)
The CFLAGS line may be able to be dropped as well.
> file a bug (if there isn't one already) and remove stabs for linux.
> Stabs still work better for solaris.
We have no plans to change the Solaris build :-)
> This still doesn't fix my problem that even the latest version of gdb
> still can't show or stop in inlined functions on 32 bit (works on 64
> bit). Is there a bug for this? It would be nice if this was
I'll leave Andrew Haley (cced) to answer this, as he's much better qualified
on this, but I think this may be similar to the problem that made us first
notice that the debug format had changed from DWARF to STABS.
> On 7/30/2012 7:42 PM, Andrew Hughes wrote:
> > Hi all,
> > It seems that following:
> > 7071904: 4/4 HotSpot: Full Debug Symbols
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/da0999c4b733
> > a number of architectures on Linux (including x86) have started
> > building with the
> > STABS debug format rather than DWARF.
> > This is presumably due to the addition of this block:
> > +ifneq ($(OBJCOPY),)
> > + FASTDEBUG_CFLAGS/ia64 = -g
> > + FASTDEBUG_CFLAGS/amd64 = -g
> > + FASTDEBUG_CFLAGS/arm = -g
> > + FASTDEBUG_CFLAGS/ppc = -g
> > + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH))
> > + ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),)
> > + FASTDEBUG_CFLAGS += -gstabs
> > + endif
> > +
> > + OPT_CFLAGS/ia64 = -g
> > + OPT_CFLAGS/amd64 = -g
> > + OPT_CFLAGS/arm = -g
> > + OPT_CFLAGS/ppc = -g
> > + OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH))
> > + ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
> > + OPT_CFLAGS += -gstabs
> > + endif
> > +endif
> > +
> > Prior to this, I don't believe product builds had debug information
> > by default. You'd
> > have to set DEBUG_BINARIES (something we do).
> > Is there a reason to use STABS any more? For our part, it's
> > causing bugs such as:
> > https://bugzilla.redhat.com/show_bug.cgi?id=841057
> > 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 libjvm_g.so 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.
> > 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?
> > 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
> > :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
More information about the hotspot-dev