Use of STABS debug format
ahughes at redhat.com
Mon Jul 30 16:42:37 PDT 2012
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:
+ 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
+ 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
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:
# 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 :-)
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