[Libreoffice] [PATCH] Use -gdwarf-4 by default if possible (was Re: Even more debugging info)

[Lubos Lunak]

On Thursday 01 of December 2011, Lubos Lunak wrote:
> On Wednesday 30 of November 2011, Tom Tromey wrote:
> > 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.

 As a followup, I've already noticed that gdb-7.2 has some trouble with 
completing C++ function names if the libs have been built with -gdwarf-4, but 
upgrading to gdb-7.3 fixed that, and I remember gdb used to have these kind 
of problems already somewhen without -gdwarf-4, so I don't that's such a 
serious problem. As for the rest of the tools listed above that I haven't 
tried, I think they're not used widely enough to be a blocker for this.

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

 So, how about the attached patch? If it's ok, I will still wait until 3.5 has 
been branched off, just in case. I also have no idea if this should be 
enabled for the WNT_INTEL_GCC target too, but it and unxgcc were the only two 
to use -ggdbX flags.

-- 
 Lubos Lunak
 l.lunak at suse.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdwarf4.diff
Type: text/x-diff
Size: 3185 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111201/83ebec07/attachment.diff>