Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Wednesday 30 of November 2011, Tom Tromey wrote:
"Stephan" == Stephan Bergmann <sbergman@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@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.