[gdb/exp] Handle DW_OP_GNU_variable_value refs to abstract dies
authorTom de Vries <tdevries@suse.de>
Fri, 24 Aug 2018 10:01:10 +0000 (12:01 +0200)
committerTom de Vries <tdevries@suse.de>
Wed, 5 Sep 2018 08:39:19 +0000 (10:39 +0200)
commite4a62c65fa8fe6a48b6ff564f45c1ac535f10f14
treec4544b77a6215000f38d8c99cb929beb6d9e433e
parent2b69821e70c7f648fa31f5d5110021a156158432
[gdb/exp] Handle DW_OP_GNU_variable_value refs to abstract dies

Consider a vla variable 'a' in function f1:
...
 <2><1a7>: Abbrev Number: 11 (DW_TAG_variable)
    <1a8>   DW_AT_description : a
    <1aa>   DW_AT_abstract_origin: <0x311>
...
with abstract origin 'a':
...
 <2><311>: Abbrev Number: 3 (DW_TAG_variable)
    <312>   DW_AT_name        : a
    <317>   DW_AT_type        : <0x325>
...
and inherited abstract vla type:
...
 <1><325>: Abbrev Number: 9 (DW_TAG_array_type)
    <326>   DW_AT_type        : <0x33a>
 <2><32e>: Abbrev Number: 10 (DW_TAG_subrange_type)
    <32f>   DW_AT_type        : <0x2ea>
    <333>   DW_AT_upper_bound : 5 byte block: fd 1b 3 0 0
                                (DW_OP_GNU_variable_value: <0x31b>)
...
where the upper bound refers to this artificial variable D.1922 without location
attribute:
...
 <2><31b>: Abbrev Number: 8 (DW_TAG_variable)
    <31c>   DW_AT_description : (indirect string, offset: 0x39a): D.1922
    <320>   DW_AT_type        : <0x2ea>
    <324>   DW_AT_artificial  : 1
...

Currently, when we execute "p sizeof (a)" in f1, the upper bound is calculated
by evaluating the DW_OP_GNU_variable_value expression referring to D.1922, but
since that die doesn't have a location attribute, we get:
...
value has been optimized out
...

However, there's also artificial variable D.4283 that is sibling of vla
variable 'a', has artificial variable D.1922 as abstract origin, and has a
location attribute:
...
 <2><1ae>: Abbrev Number: 12 (DW_TAG_variable)
    <1af>   DW_AT_description : (indirect string, offset: 0x1f8): D.4283
    <1b3>   DW_AT_abstract_origin: <0x31b>
    <1b7>   DW_AT_location    : 11 byte block: 75 1 8 20 24 8 20 26 31 1c 9f
                                (DW_OP_breg5 (rdi):1; DW_OP_const1u: 32;
 DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
 DW_OP_lit1; DW_OP_minus; DW_OP_stack_value)
...

The intended behaviour for DW_OP_GNU_variable_value is to find a die that
refers to D.1922 as abstract origin, has a location attribute and is
'in scope', so the expected behaviour is:
...
$1 = 6
...

The 'in scope' concept can be thought of as variable D.1922 having name
attribute "D.1922", and variable D.4283 inheriting that attribute, resulting
in D.4283 being declared with name "D.1922" alongside vla a in f1, and when we
lookup "DW_OP_GNU_variable_value D.1922", it should work as if we try to find
the value of a variable named "D.1922" on the gdb command line using
"p D.1922", and we should return the value of D.4283.

This patch fixes the case described above, by:
- adding a field abstract_to_concrete to struct dwarf2_per_objfile,
- using that field to keep track of which concrete dies are instances of an
  abstract die, and
- using that information when getting the value DW_OP_GNU_variable_value.

Build and reg-tested on x86_64-linux.

2018-09-05  Tom de Vries  <tdevries@suse.de>

* dwarf2loc.c (sect_variable_value): Call indirect_synthetic_pointer
with resolve_abstract_p == true.
(indirect_synthetic_pointer): Add resolve_abstract_p parameter,
defaulting to false. Propagate resolve_abstract_p to
dwarf2_fetch_die_loc_sect_off.
* dwarf2loc.h (dwarf2_fetch_die_loc_sect_off): Add resolve_abstract_p
parameter, defaulting to false.
* dwarf2read.c (read_variable): Add variable to abstract_to_concrete.
(dwarf2_fetch_die_loc_sect_off): Add and handle resolve_abstract_p
parameter.
* dwarf2read.h (struct die_info): Forward-declare.
(die_info_ptr): New typedef.
(struct dwarf2_per_objfile): Add abstract_to_concrete field.

* gdb.dwarf2/varval.exp: Add test.
gdb/ChangeLog
gdb/dwarf2loc.c
gdb/dwarf2loc.h
gdb/dwarf2read.c
gdb/dwarf2read.h
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.dwarf2/varval.exp