gdb/fortran: Add support for Fortran array slices at the GDB prompt
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
2020-10-08 23:45:59 +08:00
|
|
|
/* Copyright (C) 2020 Free Software Foundation, Inc.
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
/* Support classes to wrap up the process of iterating over a
|
|
|
|
multi-dimensional Fortran array. */
|
|
|
|
|
|
|
|
#ifndef F_ARRAY_WALKER_H
|
|
|
|
#define F_ARRAY_WALKER_H
|
|
|
|
|
|
|
|
#include "defs.h"
|
|
|
|
#include "gdbtypes.h"
|
|
|
|
#include "f-lang.h"
|
|
|
|
|
|
|
|
/* Class for calculating the byte offset for elements within a single
|
|
|
|
dimension of a Fortran array. */
|
|
|
|
class fortran_array_offset_calculator
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
/* Create a new offset calculator for TYPE, which is either an array or a
|
|
|
|
string. */
|
|
|
|
explicit fortran_array_offset_calculator (struct type *type)
|
|
|
|
{
|
|
|
|
/* Validate the type. */
|
|
|
|
type = check_typedef (type);
|
|
|
|
if (type->code () != TYPE_CODE_ARRAY
|
|
|
|
&& (type->code () != TYPE_CODE_STRING))
|
|
|
|
error (_("can only compute offsets for arrays and strings"));
|
|
|
|
|
|
|
|
/* Get the range, and extract the bounds. */
|
|
|
|
struct type *range_type = type->index_type ();
|
2020-12-10 02:51:57 +08:00
|
|
|
if (!get_discrete_bounds (range_type, &m_lowerbound, &m_upperbound))
|
gdb/fortran: Add support for Fortran array slices at the GDB prompt
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
2020-10-08 23:45:59 +08:00
|
|
|
error ("unable to read array bounds");
|
|
|
|
|
|
|
|
/* Figure out the stride for this array. */
|
|
|
|
struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (type));
|
|
|
|
m_stride = type->index_type ()->bounds ()->bit_stride ();
|
|
|
|
if (m_stride == 0)
|
|
|
|
m_stride = type_length_units (elt_type);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
struct gdbarch *arch = get_type_arch (elt_type);
|
|
|
|
int unit_size = gdbarch_addressable_memory_unit_size (arch);
|
|
|
|
m_stride /= (unit_size * 8);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Get the byte offset for element INDEX within the type we are working
|
|
|
|
on. There is no bounds checking done on INDEX. If the stride is
|
|
|
|
negative then we still assume that the base address (for the array
|
|
|
|
object) points to the element with the lowest memory address, we then
|
|
|
|
calculate an offset assuming that index 0 will be the element at the
|
|
|
|
highest address, index 1 the next highest, and so on. This is not
|
|
|
|
quite how Fortran works in reality; in reality the base address of
|
|
|
|
the object would point at the element with the highest address, and
|
|
|
|
we would index backwards from there in the "normal" way, however,
|
|
|
|
GDB's current value contents model doesn't support having the base
|
|
|
|
address be near to the end of the value contents, so we currently
|
|
|
|
adjust the base address of Fortran arrays with negative strides so
|
|
|
|
their base address points at the lowest memory address. This code
|
|
|
|
here is part of working around this weirdness. */
|
|
|
|
LONGEST index_offset (LONGEST index)
|
|
|
|
{
|
|
|
|
LONGEST offset;
|
|
|
|
if (m_stride < 0)
|
|
|
|
offset = std::abs (m_stride) * (m_upperbound - index);
|
|
|
|
else
|
|
|
|
offset = std::abs (m_stride) * (index - m_lowerbound);
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
|
|
|
/* The stride for the type we are working with. */
|
|
|
|
LONGEST m_stride;
|
|
|
|
|
|
|
|
/* The upper bound for the type we are working with. */
|
|
|
|
LONGEST m_upperbound;
|
|
|
|
|
|
|
|
/* The lower bound for the type we are working with. */
|
|
|
|
LONGEST m_lowerbound;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* A base class used by fortran_array_walker. There's no virtual methods
|
|
|
|
here, sub-classes should just override the functions they want in order
|
|
|
|
to specialise the behaviour to their needs. The functionality
|
|
|
|
provided in these default implementations will visit every array
|
|
|
|
element, but do nothing for each element. */
|
|
|
|
|
|
|
|
struct fortran_array_walker_base_impl
|
|
|
|
{
|
|
|
|
/* Called when iterating between the lower and upper bounds of each
|
|
|
|
dimension of the array. Return true if GDB should continue iterating,
|
|
|
|
otherwise, return false.
|
|
|
|
|
|
|
|
SHOULD_CONTINUE indicates if GDB is going to stop anyway, and should
|
|
|
|
be taken into consideration when deciding what to return. If
|
|
|
|
SHOULD_CONTINUE is false then this function must also return false,
|
|
|
|
the function is still called though in case extra work needs to be
|
|
|
|
done as part of the stopping process. */
|
|
|
|
bool continue_walking (bool should_continue)
|
|
|
|
{ return should_continue; }
|
|
|
|
|
|
|
|
/* Called when GDB starts iterating over a dimension of the array. The
|
|
|
|
argument INNER_P is true for the inner most dimension (the dimension
|
|
|
|
containing the actual elements of the array), and false for more outer
|
|
|
|
dimensions. For a concrete example of how this function is called
|
|
|
|
see the comment on process_element below. */
|
|
|
|
void start_dimension (bool inner_p)
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
/* Called when GDB finishes iterating over a dimension of the array. The
|
|
|
|
argument INNER_P is true for the inner most dimension (the dimension
|
|
|
|
containing the actual elements of the array), and false for more outer
|
|
|
|
dimensions. LAST_P is true for the last call at a particular
|
|
|
|
dimension. For a concrete example of how this function is called
|
|
|
|
see the comment on process_element below. */
|
|
|
|
void finish_dimension (bool inner_p, bool last_p)
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
/* Called when processing the inner most dimension of the array, for
|
|
|
|
every element in the array. ELT_TYPE is the type of the element being
|
|
|
|
extracted, and ELT_OFF is the offset of the element from the start of
|
|
|
|
array being walked, and LAST_P is true only when this is the last
|
|
|
|
element that will be processed in this dimension.
|
|
|
|
|
|
|
|
Given this two dimensional array ((1, 2) (3, 4)), the calls to
|
|
|
|
start_dimension, process_element, and finish_dimension look like this:
|
|
|
|
|
|
|
|
start_dimension (false);
|
|
|
|
start_dimension (true);
|
|
|
|
process_element (TYPE, OFFSET, false);
|
|
|
|
process_element (TYPE, OFFSET, true);
|
|
|
|
finish_dimension (true, false);
|
|
|
|
start_dimension (true);
|
|
|
|
process_element (TYPE, OFFSET, false);
|
|
|
|
process_element (TYPE, OFFSET, true);
|
|
|
|
finish_dimension (true, true);
|
|
|
|
finish_dimension (false, true); */
|
|
|
|
void process_element (struct type *elt_type, LONGEST elt_off, bool last_p)
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
};
|
|
|
|
|
|
|
|
/* A class to wrap up the process of iterating over a multi-dimensional
|
|
|
|
Fortran array. IMPL is used to specialise what happens as we walk over
|
|
|
|
the array. See class FORTRAN_ARRAY_WALKER_BASE_IMPL (above) for the
|
|
|
|
methods than can be used to customise the array walk. */
|
|
|
|
template<typename Impl>
|
|
|
|
class fortran_array_walker
|
|
|
|
{
|
|
|
|
/* Ensure that Impl is derived from the required base class. This just
|
|
|
|
ensures that all of the required API methods are available and have a
|
|
|
|
sensible default implementation. */
|
|
|
|
gdb_static_assert ((std::is_base_of<fortran_array_walker_base_impl,Impl>::value));
|
|
|
|
|
|
|
|
public:
|
|
|
|
/* Create a new array walker. TYPE is the type of the array being walked
|
|
|
|
over, and ADDRESS is the base address for the object of TYPE in
|
|
|
|
memory. All other arguments are forwarded to the constructor of the
|
|
|
|
template parameter class IMPL. */
|
|
|
|
template <typename ...Args>
|
|
|
|
fortran_array_walker (struct type *type, CORE_ADDR address,
|
|
|
|
Args... args)
|
|
|
|
: m_type (type),
|
|
|
|
m_address (address),
|
|
|
|
m_impl (type, address, args...)
|
|
|
|
{
|
|
|
|
m_ndimensions = calc_f77_array_dims (m_type);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Walk the array. */
|
|
|
|
void
|
|
|
|
walk ()
|
|
|
|
{
|
|
|
|
walk_1 (1, m_type, 0, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
/* The core of the array walking algorithm. NSS is the current
|
|
|
|
dimension number being processed, TYPE is the type of this dimension,
|
|
|
|
and OFFSET is the offset (in bytes) for the start of this dimension. */
|
|
|
|
void
|
|
|
|
walk_1 (int nss, struct type *type, int offset, bool last_p)
|
|
|
|
{
|
|
|
|
/* Extract the range, and get lower and upper bounds. */
|
|
|
|
struct type *range_type = check_typedef (type)->index_type ();
|
|
|
|
LONGEST lowerbound, upperbound;
|
2020-12-10 02:51:57 +08:00
|
|
|
if (!get_discrete_bounds (range_type, &lowerbound, &upperbound))
|
gdb/fortran: Add support for Fortran array slices at the GDB prompt
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
2020-10-08 23:45:59 +08:00
|
|
|
error ("failed to get range bounds");
|
|
|
|
|
|
|
|
/* CALC is used to calculate the offsets for each element in this
|
|
|
|
dimension. */
|
|
|
|
fortran_array_offset_calculator calc (type);
|
|
|
|
|
|
|
|
m_impl.start_dimension (nss == m_ndimensions);
|
|
|
|
|
|
|
|
if (nss != m_ndimensions)
|
|
|
|
{
|
|
|
|
/* For dimensions other than the inner most, walk each element and
|
|
|
|
recurse while peeling off one more dimension of the array. */
|
|
|
|
for (LONGEST i = lowerbound;
|
|
|
|
m_impl.continue_walking (i < upperbound + 1);
|
|
|
|
i++)
|
|
|
|
{
|
|
|
|
/* Use the index and the stride to work out a new offset. */
|
|
|
|
LONGEST new_offset = offset + calc.index_offset (i);
|
|
|
|
|
|
|
|
/* Now print the lower dimension. */
|
|
|
|
struct type *subarray_type
|
|
|
|
= TYPE_TARGET_TYPE (check_typedef (type));
|
|
|
|
walk_1 (nss + 1, subarray_type, new_offset, (i == upperbound));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* For the inner most dimension of the array, process each element
|
|
|
|
within this dimension. */
|
|
|
|
for (LONGEST i = lowerbound;
|
|
|
|
m_impl.continue_walking (i < upperbound + 1);
|
|
|
|
i++)
|
|
|
|
{
|
|
|
|
LONGEST elt_off = offset + calc.index_offset (i);
|
|
|
|
|
|
|
|
struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (type));
|
|
|
|
if (is_dynamic_type (elt_type))
|
|
|
|
{
|
|
|
|
CORE_ADDR e_address = m_address + elt_off;
|
|
|
|
elt_type = resolve_dynamic_type (elt_type, {}, e_address);
|
|
|
|
}
|
|
|
|
|
|
|
|
m_impl.process_element (elt_type, elt_off, (i == upperbound));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
m_impl.finish_dimension (nss == m_ndimensions, last_p || nss == 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The array type being processed. */
|
|
|
|
struct type *m_type;
|
|
|
|
|
|
|
|
/* The address in target memory for the object of M_TYPE being
|
|
|
|
processed. This is required in order to resolve dynamic types. */
|
|
|
|
CORE_ADDR m_address;
|
|
|
|
|
|
|
|
/* An instance of the template specialisation class. */
|
|
|
|
Impl m_impl;
|
|
|
|
|
|
|
|
/* The total number of dimensions in M_TYPE. */
|
|
|
|
int m_ndimensions;
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif /* F_ARRAY_WALKER_H */
|