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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Siva Narayanan
Hi,

With a test code like so:

struct foo {
   int fooMember;
};

extern struct foo fooDeclared;

void asymbol() { }

We find that gcc6 (or even gcc7) generates a lot more debug
information. "readelf -wi <.o file>" shows the following.

 <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
    <2e>   DW_AT_name        : foo
    <32>   DW_AT_byte_size   : 4
    <33>   DW_AT_decl_file   : 1
    <34>   DW_AT_decl_line   : 1
    <35>   DW_AT_sibling     : <0x46>
 <2><39>: Abbrev Number: 3 (DW_TAG_member)
    <3a>   DW_AT_name        : (indirect string, offset: 0xc): fooMember
    <3e>   DW_AT_decl_file   : 1
    <3f>   DW_AT_decl_line   : 2
    <40>   DW_AT_type        : <0x46>
    <44>   DW_AT_data_member_location: 0
 <2><45>: Abbrev Number: 0
 <1><46>: Abbrev Number: 4 (DW_TAG_base_type)
    <47>   DW_AT_byte_size   : 4
    <48>   DW_AT_encoding    : 5 (signed)
    <49>   DW_AT_name        : int
 <1><4d>: Abbrev Number: 5 (DW_TAG_variable)
    <4e>   DW_AT_name        : (indirect string, offset: 0x0): fooDeclared
    <52>   DW_AT_decl_file   : 1
    <53>   DW_AT_decl_line   : 5
    <54>   DW_AT_type        : <0x2d>
    <58>   DW_AT_external    : 1
    <58>   DW_AT_declaration : 1

The compilation line is: "gcc -o t.o -c -g t.c" in all attempts.

It is not at all obvious why there is debug information being
generated for an unused "extern" (struct foo, "fooDeclared")

We don't observe this with gcc4 or gcc5. In our environment this seems
to result in the non-trivial increase of object file size (on disk),
resulting in other downstream issues.

So we are trying to understand if some config option has some how
become default.

gcc 5.4 version, built from Fedora based sources: gcc version 5.4.0
20160603 (Red Hat 5.4.0-6) (GCC) - does not produce this behavior.

gcc 6.3 version which exhibits this new behavior: gcc version 6.3.1
20170216 (Red Hat 6.3.1-3) (GCC). We picked the source rpm for this
from F25.

We also tested on gcc 6.2 (Ubuntu Yakkety, and observed the same new
behavior): gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)

Many thanks.
Reply | Threaded
Open this post in threaded view
|

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

Siva Narayanan
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.

We appreciate any input and help.

Thanks.

On Thu, Jun 15, 2017 at 2:45 PM, Siva Narayanan <[hidden email]> wrote:

> Hi,
>
> With a test code like so:
>
> struct foo {
>    int fooMember;
> };
>
> extern struct foo fooDeclared;
>
> void asymbol() { }
>
> We find that gcc6 (or even gcc7) generates a lot more debug
> information. "readelf -wi <.o file>" shows the following.
>
>  <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
>     <2e>   DW_AT_name        : foo
>     <32>   DW_AT_byte_size   : 4
>     <33>   DW_AT_decl_file   : 1
>     <34>   DW_AT_decl_line   : 1
>     <35>   DW_AT_sibling     : <0x46>
>  <2><39>: Abbrev Number: 3 (DW_TAG_member)
>     <3a>   DW_AT_name        : (indirect string, offset: 0xc): fooMember
>     <3e>   DW_AT_decl_file   : 1
>     <3f>   DW_AT_decl_line   : 2
>     <40>   DW_AT_type        : <0x46>
>     <44>   DW_AT_data_member_location: 0
>  <2><45>: Abbrev Number: 0
>  <1><46>: Abbrev Number: 4 (DW_TAG_base_type)
>     <47>   DW_AT_byte_size   : 4
>     <48>   DW_AT_encoding    : 5 (signed)
>     <49>   DW_AT_name        : int
>  <1><4d>: Abbrev Number: 5 (DW_TAG_variable)
>     <4e>   DW_AT_name        : (indirect string, offset: 0x0): fooDeclared
>     <52>   DW_AT_decl_file   : 1
>     <53>   DW_AT_decl_line   : 5
>     <54>   DW_AT_type        : <0x2d>
>     <58>   DW_AT_external    : 1
>     <58>   DW_AT_declaration : 1
>
> The compilation line is: "gcc -o t.o -c -g t.c" in all attempts.
>
> It is not at all obvious why there is debug information being
> generated for an unused "extern" (struct foo, "fooDeclared")
>
> We don't observe this with gcc4 or gcc5. In our environment this seems
> to result in the non-trivial increase of object file size (on disk),
> resulting in other downstream issues.
>
> So we are trying to understand if some config option has some how
> become default.
>
> gcc 5.4 version, built from Fedora based sources: gcc version 5.4.0
> 20160603 (Red Hat 5.4.0-6) (GCC) - does not produce this behavior.
>
> gcc 6.3 version which exhibits this new behavior: gcc version 6.3.1
> 20170216 (Red Hat 6.3.1-3) (GCC). We picked the source rpm for this
> from F25.
>
> We also tested on gcc 6.2 (Ubuntu Yakkety, and observed the same new
> behavior): gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)
>
> Many thanks.
Reply | Threaded
Open this post in threaded view
|

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

Richard Biener-2
On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <[hidden email]> 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.

Richard.

> We appreciate any input and help.
>
> Thanks.
>
> On Thu, Jun 15, 2017 at 2:45 PM, Siva Narayanan <[hidden email]> wrote:
>> Hi,
>>
>> With a test code like so:
>>
>> struct foo {
>>    int fooMember;
>> };
>>
>> extern struct foo fooDeclared;
>>
>> void asymbol() { }
>>
>> We find that gcc6 (or even gcc7) generates a lot more debug
>> information. "readelf -wi <.o file>" shows the following.
>>
>>  <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
>>     <2e>   DW_AT_name        : foo
>>     <32>   DW_AT_byte_size   : 4
>>     <33>   DW_AT_decl_file   : 1
>>     <34>   DW_AT_decl_line   : 1
>>     <35>   DW_AT_sibling     : <0x46>
>>  <2><39>: Abbrev Number: 3 (DW_TAG_member)
>>     <3a>   DW_AT_name        : (indirect string, offset: 0xc): fooMember
>>     <3e>   DW_AT_decl_file   : 1
>>     <3f>   DW_AT_decl_line   : 2
>>     <40>   DW_AT_type        : <0x46>
>>     <44>   DW_AT_data_member_location: 0
>>  <2><45>: Abbrev Number: 0
>>  <1><46>: Abbrev Number: 4 (DW_TAG_base_type)
>>     <47>   DW_AT_byte_size   : 4
>>     <48>   DW_AT_encoding    : 5 (signed)
>>     <49>   DW_AT_name        : int
>>  <1><4d>: Abbrev Number: 5 (DW_TAG_variable)
>>     <4e>   DW_AT_name        : (indirect string, offset: 0x0): fooDeclared
>>     <52>   DW_AT_decl_file   : 1
>>     <53>   DW_AT_decl_line   : 5
>>     <54>   DW_AT_type        : <0x2d>
>>     <58>   DW_AT_external    : 1
>>     <58>   DW_AT_declaration : 1
>>
>> The compilation line is: "gcc -o t.o -c -g t.c" in all attempts.
>>
>> It is not at all obvious why there is debug information being
>> generated for an unused "extern" (struct foo, "fooDeclared")
>>
>> We don't observe this with gcc4 or gcc5. In our environment this seems
>> to result in the non-trivial increase of object file size (on disk),
>> resulting in other downstream issues.
>>
>> So we are trying to understand if some config option has some how
>> become default.
>>
>> gcc 5.4 version, built from Fedora based sources: gcc version 5.4.0
>> 20160603 (Red Hat 5.4.0-6) (GCC) - does not produce this behavior.
>>
>> gcc 6.3 version which exhibits this new behavior: gcc version 6.3.1
>> 20170216 (Red Hat 6.3.1-3) (GCC). We picked the source rpm for this
>> from F25.
>>
>> We also tested on gcc 6.2 (Ubuntu Yakkety, and observed the same new
>> behavior): gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)
>>
>> Many thanks.
Reply | Threaded
Open this post in threaded view
|

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

Jason Merrill
On Mon, Jun 19, 2017 at 3:45 AM, Richard Biener
<[hidden email]> wrote:

> On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <[hidden email]> 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?

Jason
Reply | Threaded
Open this post in threaded view
|

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

Richard Biener-2
On Mon, Jun 19, 2017 at 7:18 PM, Jason Merrill <[hidden email]> wrote:

> On Mon, Jun 19, 2017 at 3:45 AM, Richard Biener
> <[hidden email]> wrote:
>> On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Peter Edwards
I've submitted bug 81135 to track this -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135

On Tue, Jun 20, 2017 at 8:27 AM, Richard Biener
<[hidden email]> wrote:

> On Mon, Jun 19, 2017 at 7:18 PM, Jason Merrill <[hidden email]> wrote:
>> On Mon, Jun 19, 2017 at 3:45 AM, Richard Biener
>> <[hidden email]> wrote:
>>> On Sat, Jun 17, 2017 at 9:09 AM, Siva Narayanan <[hidden email]> 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