Use of STABS debug format (original) (raw)

Andrew Hughes 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 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

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),) > + FASTDEBUGCFLAGS/ia64 = -g > + FASTDEBUGCFLAGS/amd64 = -g > + FASTDEBUGCFLAGS/arm = -g > + FASTDEBUGCFLAGS/ppc = -g > + FASTDEBUGCFLAGS += (DEBUGCFLAGS/(DEBUGCFLAGS/(DEBUGCFLAGS/(BUILDARCH)) > + ifeq ($(FASTDEBUGCFLAGS/$(BUILDARCH)),) > + FASTDEBUGCFLAGS += -gstabs > + endif > + > + OPTCFLAGS/ia64 = -g > + OPTCFLAGS/amd64 = -g > + OPTCFLAGS/arm = -g > + OPTCFLAGS/ppc = -g > + OPTCFLAGS += (OPTCFLAGS/(OPTCFLAGS/(OPTCFLAGS/(BUILDARCH)) > + ifeq ($(OPTCFLAGS/$(BUILDARCH)),) > + OPTCFLAGS += -gstabs > + endif > +endif > + > > Prior to this, I don't believe product builds had debug information > by default. You'd > have to set DEBUGBINARIES (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/showbug.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 libjvmg.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

More information about the hotspot-dev mailing list