Re: PING^2: [patch] pr/54508: fix incomplete debug information for class

[<Paul_Koning at Dell dot com>]

On Oct 5, 2012, at 11:34 AM, <Paul_Koning@Dell.com>
 <Paul_Koning@Dell.com> wrote:

> 
> On Oct 5, 2012, at 4:16 AM, Jakub Jelinek wrote:
> 
>> On Thu, Oct 04, 2012 at 05:26:11PM -0700, Cary Coutant wrote:
>>>> Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C
>>>> ===================================================================
>>>> --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C     (revision 192048)
>>>> +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C     (working copy)
>>>> @@ -59,11 +59,11 @@
>>>> // { dg-final { scan-assembler "foo\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler "staticfn1\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler "staticfn2\[^\n\r\]*DW_AT_name" } }
>>>> -// { dg-final { scan-assembler-not "staticfn3\[^\n\r\]*DW_AT_name" } }
>>>> -// { dg-final { scan-assembler-not "staticfn4\[^\n\r\]*DW_AT_name" } }
>>>> +// { dg-final { scan-assembler "staticfn3\[^\n\r\]*DW_AT_name" } }
>>>> +// { dg-final { scan-assembler "staticfn4\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler-not "staticfn5\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler-not "staticfn6\[^\n\r\]*DW_AT_name" } }
>>>> -// { dg-final { scan-assembler-not "method1\[^\n\r\]*DW_AT_name" } }
>>>> +// { dg-final { scan-assembler "method1\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler "arg1\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler "arg2\[^\n\r\]*DW_AT_name" } }
>>>> // { dg-final { scan-assembler "arg3\[^\n\r\]*DW_AT_name" } }
>>> 
>>> The fact that these two tests were specifically checking for the
>>> absence of staticfn3 and staticfn4 leads me to believe that the
>>> current behavior is deliberate. Jakub, that change was yours (it dates
>>> back to November 2008). Are you OK with Paul's change?
>> 
>> Yes, thought it would be interesting to get some .debug_info size growth
>> numbers for a few projects (say libstdc++.so and some larger C++ codebase
>> (some KDE core library, or OO.o) without/with the patch, to see how much
>> does it bring with it (I'm not that much worried about the DW_TAG_subprogram
>> added itself, but about about types it will additionally bring in).
>> We have dwz and likely would get most of the growth back due to redundancy
>> removal though.
>> 
>> 	Jakub
> 
> I did a quick test on a large application of ours where this issue was causing trouble.  Without the patch, it generates 115 MB of debug data; with the patch, that grows to 120 MB.

So given the comments, is this patch now ok to commit?

Thanks,
	paul