Use of STABS debug format

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, 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'.
> 
> This answers my question about DEBUG_BINARIES. 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 @@
> >   # 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.
> 
> 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 DEBUG_BINARIES is:
> 
>   # DEBUG_BINARIES overrides everything, use full -g debug
>   information
>   ifeq ($(DEBUG_BINARIES), true)
> !  DEBUG_CFLAGS =
> +  OPT_CFLAGS =
> +  FASTDEBUG_CFLAGS =
>     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 DEBUG_BINARIES 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),)
> >>> + 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