On Thursday 01 of December 2011, Lionel Elie Mamane wrote:
> On Thu, Dec 01, 2011 at 12:14:32PM +0100, Lubos Lunak wrote:
> > On Wednesday 30 of November 2011, Tom Tromey wrote:
> >> First, one must consider the tradeoffs. I always use -g3 when building
> >> gdb, because gdb uses macros fairly hea
> "Lionel" == Lionel Elie Mamane writes:
Tom> In a recent-enough GCC (I don't know if it made 4.6, but anyway I
Tom> think it is in Fedora 16), there is a GNU extension to how macro
Tom> information is represented. This extension greatly reduces the size
Tom> of the macro information.
Lione
> "Lubos" == Lubos Lunak writes:
Lubos> As a sidenote, this gave me an interesting idea that I want to
Lubos> try somewhen. It might be actually helpful to explicitly not
Lubos> have debug info about macros and enclose bodies of some functions
Lubos> like uno::Reference::operator->() or boo
On Thu, Dec 01, 2011 at 12:14:32PM +0100, Lubos Lunak wrote:
> On Wednesday 30 of November 2011, Tom Tromey 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!
>> First, one must consider the tradeoffs.
On Wed, Nov 30, 2011 at 01:34:41PM -0700, Tom Tromey wrote:
> In a recent-enough GCC (I don't know if it made 4.6, but anyway I
> think it is in Fedora 16), there is a GNU extension to how macro
> information is represented. This extension greatly reduces the size
> of the macro information.
And
On Wed, Nov 30, 2011 at 11:31:19PM +0100, Michael Stahl wrote:
> an interesting data point:
> LO tree built with gcc 4.6.2 -g takes up 23G.
> extrapolating from Lubos' mail that -ggdb3 takes 4 times as much space
> the problem should be obvious :-/
I'm not sure what/how you are measuring, but wi
On Wednesday 30 of November 2011, Tom Tromey wrote:
> > "Stephan" == Stephan Bergmann 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!
On 11/30/2011 09:34 PM, Tom Tromey wrote:
"Stephan" == Stephan Bergmann writes:
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
On 30/11/11 21:34, Tom Tromey wrote:
>> "Stephan" == Stephan Bergmann 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> W
> "Stephan" == Stephan Bergmann 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 com
On Wednesday 30 of November 2011, Stephan Bergmann wrote:
> 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!
>
> Would -ggdb3 excessively increase object size co
On Wed, Nov 30, 2011 at 05:37:48PM +0100, Lionel Elie Mamane wrote:
> If nobody opposes, I propose to push it. That option is supported by
> gcc 2.95.3, so should not introduce compatibility issues.
gb_SYMBOL should not introduce full debugging symbols and Rene would likely
strongly object to havi
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!
Would -ggdb3 excessively increase object size compared to -ggdb2?
Stephan
_
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!
If nobody opposes, I propose to push it. That option is supported by
gcc 2.95.3, so should not introduce compatibility issues.
--
Lionel
>From 4b28ea46fa6fbd414663d15f
14 matches
Mail list logo
