forked from Imagelibrary/binutils-gdb
e4a62c65fa
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.