Use of STABS debug format
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),)
> + 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.
Correct. On Linux, neither product builds nor fastdebug builds
had debug info enabled.
> You'd have to set DEBUG_BINARIES (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/show_bug.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 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.
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 += $(DEBUG_CFLAGS/$(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 += $(DEBUG_CFLAGS/$(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 += $(OPT_CFLAGS/$(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:
- FASTDEBUG_* didn't have ANY debug flags set and now it does.
I tracked that back during the FDS project to a particular
bug fix, but I don't remember the details. I'm pretty sure
it was a reaction to a size related issue.
- The DEBUG_BINARIES override only resets the DEBUG_CFLAGS value
to "-g" and doesn't touch FASTDEBUG_CFLAGS or OPT_CFLAGS.
However, it does add '-g' to CFLAGS so the flag does get into
the other build configs, but I'm not sure of option ordering.
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