Use of STABS debug format (original) (raw)

Andrew Hughes ahughes at redhat.com
Tue Jul 31 10:53:43 PDT 2012

----- Original Message -----

On 7/31/12 7:26 AM, Andrew Hughes wrote: > ----- 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, x8664 and > ia64. > > This conflicts with the DEBUGBINARIES 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'.

This answers my question about DEBUGBINARIES. Looks like my changes for 7071904 broke that option.

Yes. I know we're now getting STABS on x86 where we weren't before, so I presume -gstabs is overriding -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 @@ > # DEBUGBINARIES overrides everything, use full -g debug > information > ifeq ($(DEBUGBINARIES), true) > DEBUGCFLAGS = -g > + OPTCFLAGS = -g > + FASTDEBUGCFLAGS = -g > CFLAGS += $(DEBUGCFLAGS) > endif > > The CFLAGS line may be able to be dropped as well. Actually the CFLAGS line is the only way to be sure that the '-g' gets into all build configs. At one point, there was more than "debug", "fastdebug" and "opt"...

Yes, I thought there might be an issue like that, which is why I didn't include it in the actual patch.

I think the right fix for DEBUGBINARIES is: # DEBUGBINARIES overrides everything, use full -g debug information ifeq ($(DEBUGBINARIES), true) ! DEBUGCFLAGS = + OPTCFLAGS = + FASTDEBUGCFLAGS = CFLAGS += -g endif

That looks fine. Whatever gets us back to where we were before (DWARF format debug information on all architectures for all builds with DEBUG_BINARIES) works for us.

Whether or not you want to shift to DWARF too is another matter which I'll leave up to you. The DEBUG_BINARIES solution didn't occur to me in the first mail or I probably wouldn't have even discussed the merits of STABS vs. DWARF :-)

>> I'll >> file a bug (if there isn't one already) and remove stabs for >> linux. > Thanks :-) I think we need two bugs here. One for the DEBUGBINARIES breakage and one for possibly changing to DWARF from STABS on Linux X86.

That sounds right. Our primary concern is the first of those two, and the required change looks trivial.

Dan

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