[Libreoffice] Even more debugging info

Lubos Lunak l.lunak at suse.cz
Thu Dec 1 03:14:32 PST 2011

On Wednesday 30 of November 2011, Tom Tromey wrote:
> >>>>> "Stephan" == Stephan Bergmann <sbergman at redhat.com> writes:
> Stephan> On 11/30/2011 05:37 PM, Lionel Elie Mamane wrote:
> >> Any opinion about this patch? I have it in my local repo, and it helps
> >> me when running under gdb, as gdb now knows about macros!
> Stephan> Would -ggdb3 excessively increase object size compared to -ggdb2?
> The short answer is yes, but there is a more complicated answer.
> First, one must consider the tradeoffs.  I always use -g3 when building
> gdb, because gdb uses macros fairly heavily, and because I just don't
> care about the extra space.  I prefer the convenience.  YMMV of course,
> and I don't know enough about LibreOffice to offer an opinion.

 There is hope that LibreOffice is C++ enough to actually not use macros that 
need to be stepped through.

 As a sidenote, this gave me an interesting idea that I want to try somewhen. 
It might be actually helpful to explicitly not have debug info about macros 
and enclose bodies of some functions like uno::Reference::operator->() or 
boost::shared_ptr stuff in one huge macro that'd avoid stepping through them 
(which I really hate, as it's mostly pointless).

> If you really want to shrink debuginfo, use -gdwarf-4 and
> -fdebug-types-section.  The former has been in GCC for a while, I don't
> remember when the latter was added.

 -fdebug-types-section is very new (few months), but it seems the addition was 
actually -fno-debug-types-section, allowing disabling of the feature for 
tools that cannot cope with it.

> These options cause debuginfo for 
> most big types to be shared across compilation units, a huge size win.
> This also makes gdb use less memory.

 I've tried it and it seems to save about 1/3 of .so size, so it indeed is 
very noticeable. Would it make sense to have this even enabled by default if 
gcc supports the option?

> The downside of this feature is that not all tools have been upgraded to
> understand it.  gdb works fine, but the 7 dwarves, and systemtap, and I
> think valgrind, will barf.  They will all come around eventually, though
> I am not sure when.

 I have gcc-4.5.1, gdb-7.2 and valgrind 3.6.1 (openSUSE 11.4) and after some 
quick tests I didn't notice any problems with -gdwarf-4.

 So -gdwarf-4 looks like a sensible default to me. Even if not, I'm going to 
use it (quick hack: modify your LO make script to add it to $CXXFLAGS).

 Lubos Lunak
 l.lunak at suse.cz

More information about the LibreOffice mailing list