Use of STABS debug format

[Andrew Hughes]

----- Original Message -----
> 
> I would love for stabs to go away for linux 32 bit.   I think there
> was
> 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
ia64.

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:

--- a/make/linux/makefiles/gcc.make
+++ b/make/linux/makefiles/gcc.make
@@ -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)
 endif

The CFLAGS line may be able to be dropped as well.

>   I'll
> file a bug (if there isn't one already) and remove stabs for linux.

Thanks :-)

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

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.

> 
> Thanks,
> Coleen
> 
> 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
> > :-)
> 
> 

Thanks,
-- 
Andrew :)

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