Re: Question about extra debug (DWARF) info generated by gcc6/7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 19, 2017 at 7:18 PM, Jason Merrill <jason@xxxxxxxxxx> wrote:
> On Mon, Jun 19, 2017 at 3:45 AM, Richard Biener
> <richard.guenther@xxxxxxxxx> wrote:
>> On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <sinaraya@xxxxxxxxxx> wrote:
>>> Hello all,
>>>
>>> My colleague Peter managed to use "git bisect" on the git mirror of
>>> gcc source code. The commit from a branch called "debug-early" seems
>>> like a possible point when the new behavior got introduced.
>>>
>>> We have also looked at this conversation:
>>> https://gcc.gnu.org/ml/gcc/2015-05/msg00046.html
>>>
>>> We would like to know if this work:
>>>
>>>>Shortly after the merge I'll work on a pass to prune unused decl DIEs as >we're presently creating more DIEs than mainline. This was expected, >and if I understood Jason correctly, it is ok to work on this post-merge. >However, even without such a pass, the .debug_info size difference is >reasonable:
>>>
>>> happened along with a future commit or if there is still some work
>>> pending. As I wrote, in our environment the debug_info size difference
>>> (from earlier 5.4 version of gcc) is significant that the object file
>>> size change is non-trivial with gcc 6.3.1.
>>
>> To my knowledge this hasn't happened yet.
>
> Is there an open PR for this?

I can't find one but IIRC there was one maybe only slightly related to
this and thus already "fixed".  In talking to
Pierre-Marie about some dwarf2 patch he has to not bail out early when
trying to emit early debug for
declarations (w/o struct function) I also mentioned the possibility of
always generating those DIEs but later
doing sth like the unused type DIE removal for (global) decl DIEs as
well (just do a symtab lookup at early finish
time and see if there are any references to it, if not, prune the DIE).

Deciding on if sth is used at the point we call
dwarf2out_early_global_decl seems premature given that
is called by rest_of_decl_compilation which the FEs call happily
during parsing already.

Richard.

> Jason




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux