[Bug debug/33429] New: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[Bug debug/33429] New: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[hp at gcc dot gnu dot org]

See conversation at <http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01230.html>.
The changed default for that option exposes the bug; -femit-class-debug-always
should not be required to emit debug info for "class2".


-- 
           Summary: debug info for class2 in g++.dg/other/unused1.C
                    requires -femit-class-debug-always
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2007-09-14 06:33 -------
I forgot to mention that this likely happens everywhere, not just for
cris-axis-elf.  Compare for example
<http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00622.html>
(r128455, before the changed default of r128474) and
<http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00671.html>
(r128486, after).


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-14 06:33:22
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[hp at gcc dot gnu dot org]

------- Comment #2 from hp at gcc dot gnu dot org  2007-09-14 06:48 -------
Subject: Bug 33429

Author: hp
Date: Fri Sep 14 06:48:17 2007
New Revision: 128489

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128489
Log:
        PR debug/33429
        * g++.dg/other/unused1.C: XFAIL class2 scan.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/other/unused1.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[danglin at gcc dot gnu dot org]

------- Comment #3 from danglin at gcc dot gnu dot org  2007-09-15 18:38 -------
I'm also seeing this in 4.2.2.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2007-10-01 15:09 -------
I see this as well, on all archs for 4.2.2 (a regression from 4.2.1).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at gcc dot gnu dot org]

------- Comment #5 from jason at gcc dot gnu dot org  2008-10-15 18:28 -------
Contra Mark, this seems like a WONTFIX to me.

g++ assumes that if a class has a vtable, if we're going to do anything with it
we'll create an object of that type at some point, which will use the vtable,
and so we'll get the debug info.

This seems like a reasonable assumption to me; the only time it will be invalid
is with trivial examples like this.  No real code would try to cast to class2*
when nothing in the program ever creates a class2.  And if the user is doing
something funny, there's the -femit-class-debug-always flag.

In this case, we aren't omitting debug info for class2 because it's unused,
we're omitting it because we know we'll emit it elsewhere.

I think adding the -femit-class-debug-always flag to the testcase is the
correct fix for the testsuite failure; changing the compiler to emit debug
information more frequently would create a regression in debug info size.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[dodji at gcc dot gnu dot org]

------- Comment #6 from dodji at gcc dot gnu dot org  2008-10-15 19:36 -------
@jason: Thanks for you comment.

I am adding Mark in CC to the bug so that we can close the bug in WONTFIX
eventually, it you both agree :-)


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[mmitchel at gcc dot gnu dot org]

------- Comment #7 from mmitchel at gcc dot gnu dot org  2008-10-15 20:20 -------
The comment in the test says:

/* Make sure we didn't eliminate casted types because we thought they were      
   unused.  */

If we don't want to do that any more, I think we can just remove this test,
rather than passing it special options.

But, I think it's odd if I'm in the debugger, looking at code that says:

  return (X*)y;

if I can't say "print (X*)y".

If the type is coming from a library, we may not ever create objects of this
type.

Finally, we use vast amounts of space in object files for debug info, since we
emit the same debug info in multiple object files.  Trying to optimize by not
emitting debug info in this case doesn't seem likely to be a big win given our
overall strategy.  I don't have any data to support that claim, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at redhat dot com]

------- Comment #8 from jason at redhat dot com  2008-10-15 22:23 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

mmitchel at gcc dot gnu dot org wrote:
> /* Make sure we didn't eliminate casted types because we thought they were      
>    unused.  */

Yes, my point was that the reason we omit the debug info in this case is 
not that we think the type is unused, it's that even though we know it 
is used, we expect it to be emitted elsewhere.

> But, I think it's odd if I'm in the debugger, looking at code that says:
> 
>   return (X*)y;
> 
> if I can't say "print (X*)y".
> 
> If the type is coming from a library, we may not ever create objects of this
> type.

If the Xes are created in the library, the library should have the debug 
info we need.

I can't imagine a use for a statement like that in a program that 
doesn't have a definition of the vtable for X.  If no X has ever been 
created, then doing anything interesting with the X* will have undefined 
behavior, because it couldn't possibly point to an X.

> Finally, we use vast amounts of space in object files for debug info, since we
> emit the same debug info in multiple object files.  Trying to optimize by not
> emitting debug info in this case doesn't seem likely to be a big win given our
> overall strategy.  I don't have any data to support that claim, though.

I'm not sure what overall strategy you mean.  We try to avoid emitting 
the same info in multiple places when possible: we try to treat the 
debug info for classes as another vague linkage entity and put it with 
the vtable.  Unfortunately, it isn't yet possible to use linkonce for 
debug info because of GDB limitations, so our opportunities for 
optimization are limited.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[mark at codesourcery dot com]

------- Comment #9 from mark at codesourcery dot com  2008-10-15 22:51 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

jason at redhat dot com wrote:

>> But, I think it's odd if I'm in the debugger, looking at code that says:
>>
>>   return (X*)y;
>>
>> if I can't say "print (X*)y".
>>
>> If the type is coming from a library, we may not ever create objects of this
>> type.
> 
> If the Xes are created in the library, the library should have the debug 
> info we need.

That assumes a friendly library distributor. :-)

The library is provided to us in binary form and stripped, and if it
does have debug info it might not have come from GCC.  But, if it's
declared in a header, we can still provide debug info.

>> Finally, we use vast amounts of space in object files for debug info, since we
>> emit the same debug info in multiple object files.  Trying to optimize by not
>> emitting debug info in this case doesn't seem likely to be a big win given our
>> overall strategy.  I don't have any data to support that claim, though.
> 
> I'm not sure what overall strategy you mean.  We try to avoid emitting 
> the same info in multiple places when possible: we try to treat the 
> debug info for classes as another vague linkage entity and put it with 
> the vtable.

OK, my statement was overly strong.  I was thinking particularly of C++
templates, where the vague linkage strategy makes for lots of copies,
both in the object files, and, because we don't use COMDAT, in the final
binaries.  In that kind of C++ code, this optimization doesn't save a
significant percentage of space.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at redhat dot com]

------- Comment #10 from jason at redhat dot com  2008-10-16 18:40 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

mark at codesourcery dot com wrote:
> The library is provided to us in binary form and stripped, and if it
> does have debug info it might not have come from GCC.  But, if it's
> declared in a header, we can still provide debug info.

In which case we need to specify -femit-class-debug-always, yes.

> OK, my statement was overly strong.  I was thinking particularly of C++
> templates, where the vague linkage strategy makes for lots of copies,
> both in the object files, and, because we don't use COMDAT, in the final
> binaries.  In that kind of C++ code, this optimization doesn't save a
> significant percentage of space.

I wouldn't expect it to make a big difference with heavily templated 
code, no.

It seems to me that you're arguing that -femit-class-debug-always should 
go back to being on by default; its only effect is to control this exact 
optimization.  But the documentation says

--
This option
should be used only with debuggers that are unable to handle the way GCC
normally emits debugging information for classes because using this
option will increase the size of debugging information by as much as a
factor of two.
--

Does anyone have some recent numbers?

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[mark at codesourcery dot com]

------- Comment #11 from mark at codesourcery dot com  2008-10-16 20:37 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

jason at redhat dot com wrote:

> It seems to me that you're arguing that -femit-class-debug-always should 
> go back to being on by default; its only effect is to control this exact 
> optimization.

If that's the only effect, then, yes, I guess that's what I'm arguing.

> Does anyone have some recent numbers?

That would certainly be helpful.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[dodji at gcc dot gnu dot org]

------- Comment #12 from dodji at gcc dot gnu dot org  2008-10-20 10:20 -------
So what do we do with this PR ? Do we mark it with "waiting for feeback" until
someone comes up with numbers about debug info size ?.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at redhat dot com]

------- Comment #13 from jason at redhat dot com  2008-10-20 19:01 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

Could you (Dodji) try building libstdc++ with -femit-class-debug-always, 
and see how much it affects the size of the library?

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at redhat dot com]

------- Comment #14 from jason at redhat dot com  2008-10-20 19:02 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

Building Firefox or OpenOffice with/without the flag would also be a 
good test.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[dodji at seketeli dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]



------- Comment #15 from dodji at seketeli dot org  2008-10-21 10:15 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

jason at redhat dot com a écrit :
> ------- Comment #14 from jason at redhat dot com  2008-10-20 19:02 -------
> Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
>   requires -femit-class-debug-always
> 
> Building Firefox or OpenOffice with/without the flag would also be a 
> good test.

Sure, I will do that.

Dodji.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[dodji at seketeli dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]



------- Comment #16 from dodji at seketeli dot org  2008-10-24 10:56 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

jason at redhat dot com a écrit :
> Could you (Dodji) try building libstdc++ with -femit-class-debug-always, 
> and see how much it affects the size of the library?

So, I built libstdc++, nemiver, mozilla and openoffice with and without 
the -femit-class-debug-always. I both cases, I did build those programs 
with -g, obviously.

Below are the results of the measurements I did. The debug-info size is 
actually the total size of the elf sections which names are .debug*, 
summed up across all the binaries of a given software.
For a point of comparison, I did also measure the size of .text+data+bss 
segment for both cases.

I hope this helps.

Dodji.

=~=
Nemiver
========
[compact]
debug-info: 43686650
text+data+bss: 13403553

[emit-class-debug-always]
debug-info: 61978858
text+data+bss: 13403793

% increase of debug info size: 42%

libstdc++
=========
[compact]
debug-info: 6474724
text+data+bss: 1282176

[emit-class-debug-always]
debug-info: 6998035
text+data+bss: 1282176

% increase of debug info size: 8%

Mozilla
========
[compact]
debug-info: 882264540
text+data+bss: 60055643

[emit-class-debug-always]
debug-info: 975240699
text+data+bss: 60055739

% increase debug info size: 10,5%

OpenOffice
==========

[compact]
debug-info: 961663753
text+data+bss: 442286732

[emit-class-debug-always]
debug-info: 1010668556
text+data+bss: 442568161

% increase of debug info size: 5%
=~=


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429