Use of STABS debug format
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Jul 31 08:13:30 PDT 2012
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
>> 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
> 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)
> 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
>> 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.
>> 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
> 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.
>> On 7/30/2012 7:42 PM, Andrew Hughes wrote:
>>> Hi all,
>>> It seems that following:
>>> 7071904: 4/4 HotSpot: Full Debug Symbols
>>> 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
>>> 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:
>>> This statement:
>>> # Use the stabs format for debugging information (this is the
>>> # on gcc-2.91). It's good enough, has all the information about
>>> # 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
>>> seems redundant, given debug information is now stripped and stored
>>> 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
More information about the hotspot-dev