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