[2.3 BRANCH]: gstabs issue

[Andrew Hughes]

----- Original Message -----
> On 08/08/2012 07:11 PM, Kelly O'Hair wrote:
> 
> > I'll continue to push for Dwarf usage, but the lack of link time
> > Dwarf size reductions has made this a hard argument to win.  We
> > archive a great deal of builds for potential regression isolations,
> > and sometimes size does matter. :^(
> 
> Crikey, is that the actual reason?  I was having a great deal of
> difficulty understanding the size argument, given that we now use
> separate debuginfo.
> 

I raised that exact point (http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006253.html),
quoted below with Daniel's reply:

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

> Andrew.
> 

-- 
Andrew :)

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