mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
3c8c6de21d
Consider this Fortran type:
type :: some_type
integer, allocatable :: array_one (:,:)
integer :: a_field
integer, allocatable :: array_two (:,:)
end type some_type
And a variable declared:
type(some_type) :: some_var
Now within GDB we try this:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one =
../../src/gdb/value.c:3968: internal-error: Unexpected lazy value type.
Normally, when an internalvar ($a in this case) is created, it is
non-lazy, the value is immediately copied out of the inferior into
GDB's memory.
When printing the internalvar ($a) GDB will extract each field in
turn, so in this case `array_one`. As the original internalvar is
non-lazy then the extracted field will also be non-lazy, with its
contents immediately copied from the parent internalvar.
However, when the field has a dynamic type this is not the case, in
value_primitive_field we see that any field with dynamic type is
always created lazy. Further, the content of this field will usually
not have been captured in the contents buffer of the original value, a
field with dynamic location is effectively a pointer value contained
within the parent value, with rules in the DWARF for how to
dereference the pointer.
So, we end up with a lazy lval_internalvar_component representing a
field within an lval_internalvar. This eventually ends up in
value_fetch_lazy, which currently does not support
lval_internalvar_component, and we see the error above.
My original plan for how to handle this involved extending
value_fetch_lazy to handle lval_internalvar_component. However, when
I did this I ran into another error:
(gdb) set $a = some_var
(gdb) p $a
$1 = ( array_one = ((1, 1) (1, 1) (1, 1)), a_field = 5, array_two = ((0, 0, 0) (0, 0, 0)) )
(gdb) p $a%array_one
$2 = ((1, 1) (1, 1) (1, 1))
(gdb) p $a%array_one(1,1)
../../src/gdb/value.c:1547: internal-error: void set_value_address(value*, CORE_ADDR): Assertion `value->lval == lval_memory' failed.
The problem now is inside set_value_component_location, where we
attempt to set the address for a component if the original parent
value has a dynamic location. GDB does not expect to ever set the
address on anything other than an lval_memory value (which seems
reasonable).
In order to resolve this issue I initially thought about how an
internalvar should "capture" the value of a program variable at the
moment the var is created. In an ideal world (I think) GDB would be
able to do this even for values with dynamic type. So in our above
example doing `set $a = some_var` would capture the content of
'some_var', but also the content of 'array_one', and also 'array_two',
even though these content regions are not contained within the region
of 'some_var'.
Supporting this would require GDB values to be able to carry around
multiple non-contiguous regions of memory as content in some way,
which sounds like a pretty huge change to a core part of GDB.
So, I wondered if there was some other solution that wouldn't require
such a huge change.
What if values with a dynamic location were though of like points with
automatic dereferencing? Given this C structure:
struct foo_t {
int *val;
}
struct foo_t my_foo;
Then in GDB:
(gdb) $a = my_foo
We would expect GDB to capture the pointer value in '$a', but not the
value pointed at by the pointer. So maybe it's not that unreasonable
to think that given a dynamically typed field GDB will capture the
address of the content, but not the actual content itself.
That's what this patch does.
The approach is to catch this case in set_value_component_location.
When we create a component location (of an lval_internalvar) that has
a dynamic data location, the lval_internalvar_component is changed
into an lval_memory. After this, both of the above issues are
resolved. In the first case, the lval_memory is still lazy, but
value_fetch_lazy knows how to handle that. In the second case, when
we access an element of the array we are now accessing an element of
an lval_memory, not an lval_internalvar_component, and calling
set_value_address on an lval_memory is fine.
gdb/ChangeLog:
* value.c (set_value_component_location): Adjust the VALUE_LVAL
for internalvar components that have a dynamic location.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-dynamic-types.exp: New file.
* gdb.fortran/intvar-dynamic-types.f90: New file.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
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.