Use of STABS debug format

[Daniel D. Daugherty]

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.


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

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



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

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,