Use of STABS debug format (original) (raw)

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Jul 31 08:05:02 PDT 2012

Greetings,

There are a number of issues/questions in this e-mail and I'll see what I can do to address/reply to all of them.

On 7/30/12 5: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.

Yes, the fix for 7071904 enabled building with STABS debug format for many configs. However, the "rather than DWARF" part of the above confuses me slightly. Do you mean:

 These configs used to build with DWARF before and
 now build with STABS.

Or do you mean:

 These configs now build with debug info, but DWARF
 should have been used instead of STABS.

I suspect you mean the second interpretation.

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.

Correct. On Linux, neither product builds nor fastdebug builds had debug info enabled.

You'd have to set DEBUGBINARIES (something we do).

I believe that DEBUG_BINARIES still works as an override. At least that's what my testing so very long ago indicated.

Is there a reason to use STABS any more?

Yes, presuming that STABS still occupies less space than DWARF. I have not seen any proof to the contrary yet.

For our part, it's causing bugs such as:

https://bugzilla.redhat.com/showbug.cgi?id=841057

Based on a quick read of that bug, the problem there seems to be missing debug info. If your debug info is only there for 3 out of 500+ CUs, then something is wrong with the build process.

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.

The comment might be dated if DWARF is no longer much bigger than STABS. However, I have not seen any proof to the contrary yet.

I'm confused by "size argument seems redundant". Why does the stripping of debug info and storing it in a separate compressed file make the size argument "redundant"?

Debug info size is still an issue because we save all those artifacts for every integration job (JPRT) and for every promoted build (RE).

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?

The only reason to use STABS is that it is smaller than DWARF.

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

I don't have a problem with using STABS on Solaris and using something else on Linux.

Here's the relevant part of the changeset in question with a bit more context:

   210

#------------------------------------------------------------------------ 211 # Debug flags 212 213 # Use the stabs format for debugging information (this is the default 214 # on gcc-2.91). It's good enough, has all the information about line 215 # numbers and local variables, and libjvm_g.so is only about 16M. 216 # Change this back to "-g" if you want the most expressive format. 217 # (warning: that could easily inflate libjvm_g.so to 150M!) 218 # Note: The Itanium gcc compiler crashes when using -gstabs. 219 DEBUG_CFLAGS/ia64 = -g 220 DEBUG_CFLAGS/amd64 = -g 221 DEBUG_CFLAGS/arm = -g 222 DEBUG_CFLAGS/ppc = -g 223 DEBUG_CFLAGS += (DEBUGCFLAGS/(DEBUG_CFLAGS/(DEBUGC​FLAGS/(BUILDARCH)) 224 ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) 225 DEBUG_CFLAGS += -gstabs 226 endif 227 228 ifneq ($(OBJCOPY),) 229 FASTDEBUG_CFLAGS/ia64 = -g 230 FASTDEBUG_CFLAGS/amd64 = -g 231 FASTDEBUG_CFLAGS/arm = -g 232 FASTDEBUG_CFLAGS/ppc = -g 233 FASTDEBUG_CFLAGS += (DEBUGCFLAGS/(DEBUG_CFLAGS/(DEBUGC​FLAGS/(BUILDARCH)) 234 ifeq ($(FASTDEBUG_CFLAGS/$(BUILDARCH)),) 235 FASTDEBUG_CFLAGS += -gstabs 236 endif 237 238 OPT_CFLAGS/ia64 = -g 239 OPT_CFLAGS/amd64 = -g 240 OPT_CFLAGS/arm = -g 241 OPT_CFLAGS/ppc = -g 242 OPT_CFLAGS += (OPTCFLAGS/(OPT_CFLAGS/(OPTC​FLAGS/(BUILDARCH)) 243 ifeq ($(OPT_CFLAGS/$(BUILDARCH)),) 244 OPT_CFLAGS += -gstabs 245 endif 246 endif 247 248 # DEBUG_BINARIES overrides everything, use full -g debug information 249 ifeq ($(DEBUG_BINARIES), true) 250 DEBUG_CFLAGS = -g 251 CFLAGS += $(DEBUG_CFLAGS) 252 endif

I added the block from lines 228 -> 246. Note that I modeled the FASTDEBUG_* and OPT_* settings on the existing DEBUG_* settings. In other words, if a particular arch-config used DWARF in the DEBUG_* flags, then I preserved that choice in the new FASTDEBUG_* and OPT_* flags. If a particular arch-config defaulted to STABS, then I preserved that also.

Things to note:

It would be easy to switch the X86 arch-config from defaulting to STABS to specifically using DWARF, but I would need to see some size delta information and a good reason to make the change.

Dan

More information about the hotspot-dev mailing list