[2.3 BRANCH]: gstabs issue

Kelly O'Hair kelly.ohair at oracle.com
Wed Aug 8 11:11:28 PDT 2012


I'm just lurking on this alias, but I have a dbx developer history, and in particular debug formats.

I suspect the reason for using stabs is that they aren't necessarily smaller in the .o files than Dwarf, but when the
.so file is created, the Dwarf debug info is very significantly larger than stabs due to the stabs size optimizations
that happens at link time and NO Dwarf size optimizations at link time.
I'm not 100% up on what Linux/gcc/ld is doing at link time, but when Dwarf came on the scene
many years ago, the plan was to have the linker process the debug information and do some folding of the
graph a bit so the size would be significantly reduced, similar to what has always happened with stabs.
I have no idea what the status of that is, it never happened in the Solaris world, just not sure about Linux.

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. :^(   But I'd love to get rid of all use of stabs myself.

-kto

On Aug 8, 2012, at 8:26 AM, Andrew Hughes wrote:

> ----- Original Message -----
>> On 08/08/2012 03:56 PM, Andrew Hughes wrote:
>>> So is this ok to go in 2.3?  Presumably 2.2 suffers as well (I
>>> believe that's where
>>> we hit it)?
>> 
>> Yes.  It's better than what we have ATM, but until STABS is gone is
>> unfinished.
>> 
> 
> Well, feel free to try and convince them :-)
> 
> Mark Wielaard and I have both already tried without much success.
> 
>> 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
> 




More information about the distro-pkg-dev mailing list