public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* dwarf2 - multiple DW_TAG_variable for global variable
@ 2010-01-05  7:34 Nenad Vukicevic
  2010-01-09 20:40 ` Nenad Vukicevic
  0 siblings, 1 reply; 6+ messages in thread
From: Nenad Vukicevic @ 2010-01-05  7:34 UTC (permalink / raw)
  To: gcc

I installed gcc-4.5-20091224 snapshot and noticed that for simple 
variable declaration
I get two DW_TAG_variable dies in the object file. For example, the 
following
code

int xxxxx;
main()
{xxxxx=1;}

generates (with -g -gdwarf2 -O0 switches):

<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55>   DW_AT_name        : (indirect string, offset: 0x36): xxxxx
<59>   DW_AT_decl_file   : 1
<5a>   DW_AT_decl_line   : 1
<5b>   DW_AT_type        : <0x4d>
<5f>   DW_AT_external    : 1
<60>   DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62>   DW_AT_name        : (indirect string, offset: 0x36): xxxxx
<66>   DW_AT_decl_file   : 1
<67>   DW_AT_decl_line   : 1
<68>   DW_AT_type        : <0x4d>
<6c>   DW_AT_external    : 1
<6d>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

Is the above normal? 4.3.2 compiler generates only one die, the second 
one with
DW_AT_location attribute, which is correct.

I also noticed that this example (were variable is not used):

int xxxxx;
main()
{}

generates only one DW_TAG_variable, the one  with DW_AT_location, which 
again
should be correct.

I ran into this problem by porting some GDB code that uses DWARF2 and 
got surprised
to see this change from the previous version of gcc (4.3).

Thanks,
Nenad


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2 - multiple DW_TAG_variable for global variable
  2010-01-05  7:34 dwarf2 - multiple DW_TAG_variable for global variable Nenad Vukicevic
@ 2010-01-09 20:40 ` Nenad Vukicevic
  2010-01-09 21:02   ` Gary Funck
  0 siblings, 1 reply; 6+ messages in thread
From: Nenad Vukicevic @ 2010-01-09 20:40 UTC (permalink / raw)
  To: gcc; +Cc: jan.kratochvil, Gary Funck

This dwarf code started appearing since this patch:

------------------------------------------------------------------------
r145293 | jakub | 2009-03-30 14:35:03 +0000 (Mon, 30 Mar 2009) | 11 lines

         PR debug/39563
         * c-decl.c (struct c_binding): Add locus field.
         (bind): Add locus argument, set locus field from it.
         (pop_scope): For b->nested VAR_DECL or FUNCTION_DECL,
         add a DECL_EXTERNAL copy of b->decl to current BLOCK_VARS.
         (push_file_scope, pushtag, pushdecl, pushdecl_top_level,
         implicitly_declare, undeclared_variable, lookup_label,
         declare_label, c_make_fname_decl, c_builtin_function,
         c_builtin_function_ext_scope, store_parm_decls_newstyle): Adjust
         bind callers.

Jan, can you confirm that this is indeed the correct DWARF that is being generated.

Thank you,
Nenad



On 1/4/10 11:34 PM, Nenad Vukicevic wrote:
> I installed gcc-4.5-20091224 snapshot and noticed that for simple 
> variable declaration
> I get two DW_TAG_variable dies in the object file. For example, the 
> following
> code
>
> int xxxxx;
> main()
> {xxxxx=1;}
>
> generates (with -g -gdwarf2 -O0 switches):
>
> <1><54>: Abbrev Number: 4 (DW_TAG_variable)
> <55>   DW_AT_name        : (indirect string, offset: 0x36): xxxxx
> <59>   DW_AT_decl_file   : 1
> <5a>   DW_AT_decl_line   : 1
> <5b>   DW_AT_type        : <0x4d>
> <5f>   DW_AT_external    : 1
> <60>   DW_AT_declaration : 1
> <1><61>: Abbrev Number: 5 (DW_TAG_variable)
> <62>   DW_AT_name        : (indirect string, offset: 0x36): xxxxx
> <66>   DW_AT_decl_file   : 1
> <67>   DW_AT_decl_line   : 1
> <68>   DW_AT_type        : <0x4d>
> <6c>   DW_AT_external    : 1
> <6d>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  
> (DW_OP_addr: 0)
>
> Is the above normal? 4.3.2 compiler generates only one die, the second 
> one with
> DW_AT_location attribute, which is correct.
>
> I also noticed that this example (were variable is not used):
>
> int xxxxx;
> main()
> {}
>
> generates only one DW_TAG_variable, the one  with DW_AT_location, 
> which again
> should be correct.
>
> I ran into this problem by porting some GDB code that uses DWARF2 and 
> got surprised
> to see this change from the previous version of gcc (4.3).
>
> Thanks,
> Nenad
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2 - multiple DW_TAG_variable for global variable
  2010-01-09 20:40 ` Nenad Vukicevic
@ 2010-01-09 21:02   ` Gary Funck
  2010-01-09 21:18     ` Jan Kratochvil
  0 siblings, 1 reply; 6+ messages in thread
From: Gary Funck @ 2010-01-09 21:02 UTC (permalink / raw)
  To: jan.kratochvil; +Cc: GCC List

On 01/09/10 12:39:55, Nenad Vukicevic wrote:
> This dwarf code started appearing since this patch:

Here's the GCC bug report that led to this patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563

It references a GDB fix as well:
http://sourceware.org/ml/gdb-patches/2009-03/threads.html#00595
http://sourceware.org/ml/gdb-patches/2009-04/threads.html#00040
http://sourceware.org/ml/gdb-cvs/2009-04/msg00021.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2 - multiple DW_TAG_variable for global variable
  2010-01-09 21:02   ` Gary Funck
@ 2010-01-09 21:18     ` Jan Kratochvil
  2010-01-09 23:32       ` Nenad Vukicevic
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Kratochvil @ 2010-01-09 21:18 UTC (permalink / raw)
  To: Gary Funck; +Cc: GCC List

On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote:
> On 01/09/10 12:39:55, Nenad Vukicevic wrote:
> > This dwarf code started appearing since this patch:
> 
> Here's the GCC bug report that led to this patch:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563

Such DIEs duplicities are being tracked at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524

(Unaware how/if any were caused by the PR 39563.)


Regards,
Jan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2 - multiple DW_TAG_variable for global variable
  2010-01-09 21:18     ` Jan Kratochvil
@ 2010-01-09 23:32       ` Nenad Vukicevic
  2010-01-10  8:43         ` Jan Kratochvil
  0 siblings, 1 reply; 6+ messages in thread
From: Nenad Vukicevic @ 2010-01-09 23:32 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Gary Funck, GCC List

We used GCC regression testing to pin point PR39563 when
multiple (but not equal) definitions started appearing in
dwarf code. We used the head version of GCC, gcc-4.5.20091224
to be precise, for testing this abnormally.

I also saw appearance of DIEs duplicates you mention in PR 39524
in the following example:

extern int xxxxx;
int main(){xxxxx=1;}

gcc 4.3.2 - does NOT have duplicates
gcc 4..4.1 20090725 (REDHAT 4.4.1-2) - does have duplicates
gcc 4.4.2 - does NOT have duplicates
gcc 4.5.20091224 - does have duplicates

Duplicates are in the form described in PR39524.

In the case of this code:

int xxxxx;
int main(){xxxxx=1;}

I see duplicates in the form of:

<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55>   DW_AT_name        : (indirect string, offset: 0x38): xxxxx
<59>   DW_AT_decl_file   : 1
<5a>   DW_AT_decl_line   : 1
<5b>   DW_AT_type        : <0x4d>
<5f>   DW_AT_external    : 1
<60>   DW_AT_declaration : 1
<1><61>: Abbrev Number: 5 (DW_TAG_variable)
<62>   DW_AT_name        : (indirect string, offset: 0x38): xxxxx
<66>   DW_AT_decl_file   : 1
<67>   DW_AT_decl_line   : 1
<68>   DW_AT_type        : <0x4d>
<6c>   DW_AT_external    : 1
<6d>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

in 4.4.1 and 4.5 releases.

Any idea if this is a correct dwarf? Or must be treated as a duplicate 
somehow?

Thanks,
Nenad

On 1/9/10 1:18 PM, Jan Kratochvil wrote:
> On Sat, 09 Jan 2010 22:01:54 +0100, Gary Funck wrote:
>    
>> On 01/09/10 12:39:55, Nenad Vukicevic wrote:
>>      
>>> This dwarf code started appearing since this patch:
>>>        
>> Here's the GCC bug report that led to this patch:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
>>      
> Such DIEs duplicities are being tracked at:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
>
> (Unaware how/if any were caused by the PR 39563.)
>
>
> Regards,
> Jan
>    

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dwarf2 - multiple DW_TAG_variable for global variable
  2010-01-09 23:32       ` Nenad Vukicevic
@ 2010-01-10  8:43         ` Jan Kratochvil
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Kratochvil @ 2010-01-10  8:43 UTC (permalink / raw)
  To: Nenad Vukicevic; +Cc: Gary Funck, GCC List

On Sun, 10 Jan 2010 00:31:56 +0100, Nenad Vukicevic wrote:
...
> <1><54>: Abbrev Number: 4 (DW_TAG_variable)
> <55>   DW_AT_name        : (indirect string, offset: 0x38): xxxxx
> <59>   DW_AT_decl_file   : 1
> <5a>   DW_AT_decl_line   : 1
> <5b>   DW_AT_type        : <0x4d>
> <5f>   DW_AT_external    : 1
> <60>   DW_AT_declaration : 1
> <1><61>: Abbrev Number: 5 (DW_TAG_variable)
> <62>   DW_AT_name        : (indirect string, offset: 0x38): xxxxx
> <66>   DW_AT_decl_file   : 1
> <67>   DW_AT_decl_line   : 1
> <68>   DW_AT_type        : <0x4d>
> <6c>   DW_AT_external    : 1
> <6d>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
> 
> in 4.4.1 and 4.5 releases.
> 
> Any idea if this is a correct dwarf? Or must be treated as a
> duplicate somehow?

It does not hurt much GDB - if the debugger ignores the second definition it
looks as a declaration of external symbol and it gets correctly looked up
through the ELF (not DWARF) .symtab symbol without using DW_AT_location.

PR 39524 mentions a special scope case which gets broken by it but in common
cases it works fine.


Regards,
Jan

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-01-10  8:43 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-05  7:34 dwarf2 - multiple DW_TAG_variable for global variable Nenad Vukicevic
2010-01-09 20:40 ` Nenad Vukicevic
2010-01-09 21:02   ` Gary Funck
2010-01-09 21:18     ` Jan Kratochvil
2010-01-09 23:32       ` Nenad Vukicevic
2010-01-10  8:43         ` Jan Kratochvil

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).