DW_TAG_typedef indirection causes DW_AT_data_location to be ignored

[Jonas Maebe <jonas dot maebe at elis dot ugent dot be>]

Hello,

branch (revision): archer-jankratochvil-vla  
(9455db1d51d5627bac7085f161100dec3600e676)

I've noticed that if a variable's type is defined by referring to a  
TAG_typedef which in turn refers to the actual type definition, then  
the DW_AT_data_location attribute for this type will be ignored. It  
works fine if the variable's type directly points to the type  
definition.

I.e., in this case, the DW_AT_data_location is ignored:

***
 <1><84>: Abbrev Number: 3 (DW_TAG_variable)
  <85>     DW_AT_name        : a
  <87>     DW_AT_location    : 5 byte block: 3 0 0 0 0  (DW_OP_addr: 0)
  <8d>     DW_AT_type        : <#fb>

...

 <1><fb>: Abbrev Number: 8 (DW_TAG_typedef)
  <fc>     DW_AT_name        : tdab
  <101>     DW_AT_type        : <#105>
 <1><105>: Abbrev Number: 9 (DW_TAG_array_type)
  <106>     DW_AT_name        : tdab
  <10b>     DW_AT_stride_size : 32
  <10c>     DW_AT_data_location: 2 byte block: 97 6      
(DW_OP_push_object_address; DW_OP_deref)
  <10f>     DW_AT_type        : <#140>  (longint)
 <2><113>: Abbrev Number: 10 (DW_TAG_subrange_type)
  <114>     DW_AT_lower_bound : 0
  <115>     DW_AT_upper_bound : 5 byte block: 97 6 34 1c 6       
(DW_OP_push_object_address; DW_OP_deref; DW_OP_lit4; DW_OP_minus;  
DW_OP_deref)
  <11b>     DW_AT_type        : <#140>
***

And in this case it works fine:

***
<1><91>: Abbrev Number: 4 (DW_TAG_variable)
  <92>     DW_AT_name        : b
  <94>     DW_AT_location    : 5 byte block: 3 4 0 0 0  (DW_OP_addr: 4)
  <9a>     DW_AT_type        : <#125>

...

 <1><125>: Abbrev Number: 12 (DW_TAG_array_type)
  <126>     DW_AT_stride_size : 32
  <127>     DW_AT_data_location: 2 byte block: 97 6      
(DW_OP_push_object_address; DW_OP_deref)
  <12a>     DW_AT_type        : <#140>
 <2><12e>: Abbrev Number: 13 (DW_TAG_subrange_type)
  <12f>     DW_AT_lower_bound : 0
  <130>     DW_AT_upper_bound : 5 byte block: 97 6 34 1c 6       
(DW_OP_push_object_address; DW_OP_deref; DW_OP_lit4; DW_OP_minus;  
DW_OP_deref)
  <136>     DW_AT_type        : <#140>
***

Sample debug session:

$ ~/archer/gdb/gdb dynarr
GNU gdb (GDB) 6.8.50.20081222-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html 
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show  
copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) b PASCALMAIN
Breakpoint 1 at 0x80480ab: file dynarr.pp, line 8.
(gdb) r
Starting program: /afs/elis.ugent.be/usr/jmaebe/private/nobackup/fpc/ 
test/dynarr

Breakpoint 1, $main () at dynarr.pp:8
8	  setlength(a,8);
Current language:  auto; currently pascal
(gdb) n
9	  a[0]:=5;
(gdb)
10	  a[1]:=6;
(gdb)
11	  a[0]:=7;
(gdb)
12	  setlength(a,5);
(gdb) p a
$1 = {-1207992280, 0, 0, 0, 0, 0, 1, 0}
(gdb) n
13	  a[2]:=8;
(gdb)
14	  a[0]:=9;
(gdb)
15	  a[4]:=10;
(gdb)
17	  setlength(b,8);
(gdb) p a
$2 = {-1207992280, 0, 0, 0, 0}
(gdb) n
18	  b[0]:=5;
(gdb)
19	  b[1]:=6;
(gdb)
20	  b[0]:=7;
(gdb)
21	  setlength(b,5);
(gdb) p b
$3 = {7, 6, 0, 0, 0, 0, 0, 0}
(gdb) n
22	  b[2]:=8;
(gdb)
23	  b[0]:=9;
(gdb)
24	  b[4]:=10;
(gdb)
25	end.
(gdb) p b
$4 = {9, 6, 8, 0, 10}


When printing "a", the first element of the displayed array is the  
pointer to the array (as stored in "a"), and the following elements  
the data in memory after "a". With b, everything is correct.

I've put the test program from the session above at http://users.elis.ugent.be/~jmaebe/archer/dynarr.tbz


Jonas

PS: should I preferably use this list or the sourceware gdb bugzilla  
page to report archer-specific bugs?