1999-04-16 01:35:26 +00:00
|
|
|
|
/* Fortran language support routines for GDB, the GNU debugger.
|
2005-01-29 00:11:12 +00:00
|
|
|
|
|
2021-01-01 12:03:39 +04:00
|
|
|
|
Copyright (C) 1993-2021 Free Software Foundation, Inc.
|
2005-01-29 00:11:12 +00:00
|
|
|
|
|
1999-04-16 01:35:26 +00:00
|
|
|
|
Contributed by Motorola. Adapted from the C parser by Farooq Butt
|
|
|
|
|
(fmbutt@engage.sps.mot.com).
|
|
|
|
|
|
1999-07-07 20:19:36 +00:00
|
|
|
|
This file is part of GDB.
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
1999-07-07 20:19:36 +00:00
|
|
|
|
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
|
2007-08-23 18:08:50 +00:00
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
1999-07-07 20:19:36 +00:00
|
|
|
|
(at your option) any later version.
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
1999-07-07 20:19:36 +00:00
|
|
|
|
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.
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
1999-07-07 20:19:36 +00:00
|
|
|
|
You should have received a copy of the GNU General Public License
|
2007-08-23 18:08:50 +00:00
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
|
|
|
|
#include "defs.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
|
#include "symtab.h"
|
2019-04-02 20:04:24 -06:00
|
|
|
|
#include "gdbtypes.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
|
#include "expression.h"
|
2019-04-02 20:04:24 -06:00
|
|
|
|
#include "parser-defs.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
|
#include "language.h"
|
|
|
|
|
#include "varobj.h"
|
|
|
|
|
#include "gdbcore.h"
|
|
|
|
|
#include "f-lang.h"
|
2000-02-08 04:39:02 +00:00
|
|
|
|
#include "valprint.h"
|
2003-05-20 01:55:18 +00:00
|
|
|
|
#include "value.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
|
#include "cp-support.h"
|
|
|
|
|
#include "charset.h"
|
|
|
|
|
#include "c-lang.h"
|
|
|
|
|
#include "target-float.h"
|
Don't include gdbarch.h from defs.h
I touched symtab.h and was surprised to see how many files were
rebuilt. I looked into it a bit, and found that defs.h includes
gdbarch.h, which in turn includes many things.
gdbarch.h is only needed by a minority ofthe files in gdb, so this
patch removes the include from defs.h and updates the fallout.
I did "wc -l" on the files in build/gdb/.deps; this patch reduces the
line count from 139935 to 137030; so there are definitely future
build-time savings here.
Note that while I configured with --enable-targets=all, it's possible
that some *-nat.c file needs an update. I could not test all of
these. The buildbot caught a few problems along these lines.
gdb/ChangeLog
2019-07-10 Tom Tromey <tom@tromey.com>
* defs.h: Don't include gdbarch.h.
* aarch64-ravenscar-thread.c, aarch64-tdep.c, alpha-bsd-tdep.h,
alpha-linux-tdep.c, alpha-mdebug-tdep.c, arch-utils.h, arm-tdep.h,
ax-general.c, btrace.c, buildsym-legacy.c, buildsym.h, c-lang.c,
cli/cli-decode.h, cli/cli-dump.c, cli/cli-script.h,
cli/cli-style.h, coff-pe-read.h, compile/compile-c-support.c,
compile/compile-cplus.h, compile/compile-loc2c.c, corefile.c,
cp-valprint.c, cris-linux-tdep.c, ctf.c, d-lang.c, d-namespace.c,
dcache.c, dicos-tdep.c, dictionary.c, disasm-selftests.c,
dummy-frame.c, dummy-frame.h, dwarf2-frame-tailcall.c,
dwarf2expr.c, expression.h, f-lang.c, frame-base.c,
frame-unwind.c, frv-linux-tdep.c, gdbarch-selftests.c, gdbtypes.h,
go-lang.c, hppa-nbsd-tdep.c, hppa-obsd-tdep.c, i386-dicos-tdep.c,
i386-tdep.h, ia64-vms-tdep.c, interps.h, language.c,
linux-record.c, location.h, m2-lang.c, m32r-linux-tdep.c,
mem-break.c, memattr.c, mn10300-linux-tdep.c, nios2-linux-tdep.c,
objfiles.h, opencl-lang.c, or1k-linux-tdep.c, p-lang.c,
parser-defs.h, ppc-tdep.h, probe.h, python/py-record-btrace.c,
record-btrace.c, record.h, regcache-dump.c, regcache.h,
riscv-fbsd-tdep.c, riscv-linux-tdep.c, rust-exp.y,
sh-linux-tdep.c, sh-nbsd-tdep.c, source-cache.c,
sparc-nbsd-tdep.c, sparc-obsd-tdep.c, sparc-ravenscar-thread.c,
sparc64-fbsd-tdep.c, std-regs.c, target-descriptions.h,
target-float.c, tic6x-linux-tdep.c, tilegx-linux-tdep.c, top.c,
tracefile.c, trad-frame.c, type-stack.h, ui-style.c, utils.c,
utils.h, valarith.c, valprint.c, varobj.c, x86-tdep.c,
xml-support.h, xtensa-linux-tdep.c, cli/cli-cmds.h: Update.
* s390-linux-nat.c, procfs.c, inf-ptrace.c: Likewise.
2019-06-09 15:21:02 -06:00
|
|
|
|
#include "gdbarch.h"
|
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 16:45:59 +01:00
|
|
|
|
#include "gdbcmd.h"
|
|
|
|
|
#include "f-array-walker.h"
|
2021-03-08 07:27:57 -07:00
|
|
|
|
#include "f-exp.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
|
|
|
|
|
|
#include <math.h>
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* Whether GDB should repack array slices created by the user. */
|
|
|
|
|
static bool repack_array_slices = false;
|
|
|
|
|
|
|
|
|
|
/* Implement 'show fortran repack-array-slices'. */
|
|
|
|
|
static void
|
|
|
|
|
show_repack_array_slices (struct ui_file *file, int from_tty,
|
|
|
|
|
struct cmd_list_element *c, const char *value)
|
|
|
|
|
{
|
|
|
|
|
fprintf_filtered (file, _("Repacking of Fortran array slices is %s.\n"),
|
|
|
|
|
value);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Debugging of Fortran's array slicing. */
|
|
|
|
|
static bool fortran_array_slicing_debug = false;
|
|
|
|
|
|
|
|
|
|
/* Implement 'show debug fortran-array-slicing'. */
|
|
|
|
|
static void
|
|
|
|
|
show_fortran_array_slicing_debug (struct ui_file *file, int from_tty,
|
|
|
|
|
struct cmd_list_element *c,
|
|
|
|
|
const char *value)
|
|
|
|
|
{
|
|
|
|
|
fprintf_filtered (file, _("Debugging of Fortran array slicing is %s.\n"),
|
|
|
|
|
value);
|
|
|
|
|
}
|
|
|
|
|
|
1999-04-16 01:35:26 +00:00
|
|
|
|
/* Local functions */
|
|
|
|
|
|
gdb/fortran: don't access non-existent type fields
When attempting to call a Fortran function for which there is no debug
information we currently trigger undefined behaviour in GDB by
accessing non-existent type fields.
The reason is that in order to prepare the arguments, for a call to a
Fortran function, we need to know the type of each argument. If the
function being called has no debug information then obviously GDB
doesn't know about the argument types and we should either give the
user an error or pick a suitable default. What we currently do is
just assume the field exist and access undefined memory, which is
clearly wrong.
The reason GDB needs to know the argument type is to tell if the
argument is artificial or not, artificial arguments will be passed by
value while non-artificial arguments will be passed by reference.
An ideal solution for this problem would be to allow the user to cast
the function to the correct type, we already do this to some degree
with the return value, for example:
(gdb) print some_func_ ()
'some_func_' has unknown return type; cast the call to its declared return type
(gdb) print (integer) some_func_ ()
$1 = 1
But if we could extend this to allow casting to the full function
type, GDB could figure out from the signature what are real
parameters, and what are artificial parameters. Maybe something like
this:
(gdb) print ((integer () (integer, double)) some_other_func_ (1, 2.3)
Alas, right now the Fortran expression parser doesn't seem to support
parsing function signatures, and we certainly don't have support for
figuring out real vs artificial arguments from a signature.
Still, I think we can prevent GDB from accessing undefined memory and
provide a reasonable default behaviour.
In this commit I:
- Only ask if the argument is artificial if the type of the argument
is actually known.
- Unknown arguments are assumed to be artificial and passed by
value (non-artificial arguments are pass by reference).
- If an artificial argument is prefixed with '&' by the user then we
treat the argument as pass-by-reference.
With these three changes we avoid undefined behaviour in GDB, and
allow the user, in most cases, to get a reasonably natural default
behaviour.
gdb/ChangeLog:
PR fortran/26155
* f-lang.c (fortran_argument_convert): Delete declaration.
(fortran_prepare_argument): New function.
(evaluate_subexp_f): Move logic to new function
fortran_prepare_argument.
gdb/testsuite/ChangeLog:
PR fortran/26155
* gdb.fortran/call-no-debug-func.f90: New file.
* gdb.fortran/call-no-debug-prog.f90: New file.
* gdb.fortran/call-no-debug.exp: New file.
2020-11-13 10:39:23 +00:00
|
|
|
|
static value *fortran_prepare_argument (struct expression *exp, int *pos,
|
|
|
|
|
int arg_num, bool is_internal_call_p,
|
|
|
|
|
struct type *func_type,
|
|
|
|
|
enum noside noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
static value *fortran_prepare_argument (struct expression *exp,
|
|
|
|
|
expr::operation *subexp,
|
|
|
|
|
int arg_num, bool is_internal_call_p,
|
|
|
|
|
struct type *func_type, enum noside noside);
|
2020-11-13 11:03:05 +00:00
|
|
|
|
|
2011-06-29 15:32:40 +00:00
|
|
|
|
/* Return the encoding that should be used for the character type
|
|
|
|
|
TYPE. */
|
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
const char *
|
|
|
|
|
f_language::get_encoding (struct type *type)
|
2011-06-29 15:32:40 +00:00
|
|
|
|
{
|
|
|
|
|
const char *encoding;
|
|
|
|
|
|
|
|
|
|
switch (TYPE_LENGTH (type))
|
|
|
|
|
{
|
|
|
|
|
case 1:
|
2021-01-28 10:12:10 -05:00
|
|
|
|
encoding = target_charset (type->arch ());
|
2011-06-29 15:32:40 +00:00
|
|
|
|
break;
|
|
|
|
|
case 4:
|
Adjust byte order variable display/change if DW_AT_endianity is present.
- Rationale:
It is possible for compilers to indicate the desired byte order
interpretation of scalar variables using the DWARF attribute:
DW_AT_endianity
A type flagged with this variable would typically use one of:
DW_END_big
DW_END_little
which instructs the debugger what the desired byte order interpretation
of the variable should be.
The GCC compiler (as of V6) has a mechanism for setting the desired byte
ordering of the fields within a structure or union. For, example, on a
little endian target, a structure declared as:
struct big {
int v;
short a[4];
} __attribute__( ( scalar_storage_order( "big-endian" ) ) );
could be used to ensure all the structure members have a big-endian
interpretation (the compiler would automatically insert byte swap
instructions before and after respective store and load instructions).
- To reproduce
GCC V8 is required to correctly emit DW_AT_endianity DWARF attributes
in all situations when the scalar_storage_order attribute is used.
A fix for (dwarf endianity instrumentation) for GCC V6-V7 can be found
in the URL field of the following PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509
- Test-case:
A new test case (testsuite/gdb.base/endianity.*) is included with this
patch.
Manual testing for mixed endianity code has also been done with GCC V8.
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509#c4
- Observed vs. expected:
Without this change, using scalar_storage_order that doesn't match the
target, such as
struct otherendian
{
int v;
} __attribute__( ( scalar_storage_order( "big-endian" ) ) );
would behave like the following on a little endian target:
Breakpoint 1 at 0x401135: file endianity.c, line 41.
(gdb) run
Starting program: /home/pjoot/freeware/t/a.out
Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.el7.x86_64
Breakpoint 1, main () at endianity.c:41
41 struct otherendian o = {3};
(gdb) n
43 do_nothing (&o); /* START */
(gdb) p o
$1 = {v = 50331648}
(gdb) p /x
$2 = {v = 0x3000000}
whereas with this gdb enhancement we can access the variable with the user
specified endianity:
Breakpoint 1, main () at endianity.c:41
41 struct otherendian o = {3};
(gdb) p o
$1 = {v = 0}
(gdb) n
43 do_nothing (&o); /* START */
(gdb) p o
$2 = {v = 3}
(gdb) p o.v = 4
$3 = 4
(gdb) p o.v
$4 = 4
(gdb) x/4xb &o.v
0x7fffffffd90c: 0x00 0x00 0x00 0x04
(observe that the 4 byte int variable has a big endian representation in the
hex dump.)
gdb/ChangeLog
2019-11-21 Peeter Joot <peeter.joot@lzlabs.com>
Byte reverse display of variables with DW_END_big, DW_END_little
(DW_AT_endianity) dwarf attributes if different than the native
byte order.
* ada-lang.c (ada_value_binop):
Use type_byte_order instead of gdbarch_byte_order.
* ada-valprint.c (printstr):
(ada_val_print_string):
* ada-lang.c (value_pointer):
(ada_value_binop):
Use type_byte_order instead of gdbarch_byte_order.
* c-lang.c (c_get_string):
Use type_byte_order instead of gdbarch_byte_order.
* c-valprint.c (c_val_print_array):
Use type_byte_order instead of gdbarch_byte_order.
* cp-valprint.c (cp_print_class_member):
Use type_byte_order instead of gdbarch_byte_order.
* dwarf2loc.c (rw_pieced_value):
Use type_byte_order instead of gdbarch_byte_order.
* dwarf2read.c (read_base_type): Handle DW_END_big,
DW_END_little
* f-lang.c (f_get_encoding):
Use type_byte_order instead of gdbarch_byte_order.
* findvar.c (default_read_var_value):
Use type_byte_order instead of gdbarch_byte_order.
* gdbtypes.c (check_types_equal):
Require matching TYPE_ENDIANITY_NOT_DEFAULT if set.
(recursive_dump_type): Print TYPE_ENDIANITY_BIG,
and TYPE_ENDIANITY_LITTLE if set.
(type_byte_order): new function.
* gdbtypes.h (TYPE_ENDIANITY_NOT_DEFAULT): New macro.
(struct main_type) <flag_endianity_not_default>:
New field.
(type_byte_order): New function.
* infcmd.c (default_print_one_register_info):
Use type_byte_order instead of gdbarch_byte_order.
* p-lang.c (pascal_printstr):
Use type_byte_order instead of gdbarch_byte_order.
* p-valprint.c (pascal_val_print):
Use type_byte_order instead of gdbarch_byte_order.
* printcmd.c (print_scalar_formatted):
Use type_byte_order instead of gdbarch_byte_order.
* solib-darwin.c (darwin_current_sos):
Use type_byte_order instead of gdbarch_byte_order.
* solib-svr4.c (solib_svr4_r_ldsomap):
Use type_byte_order instead of gdbarch_byte_order.
* stap-probe.c (stap_modify_semaphore):
Use type_byte_order instead of gdbarch_byte_order.
* target-float.c (target_float_same_format_p):
Use type_byte_order instead of gdbarch_byte_order.
* valarith.c (scalar_binop):
(value_bit_index):
Use type_byte_order instead of gdbarch_byte_order.
* valops.c (value_cast):
Use type_byte_order instead of gdbarch_byte_order.
* valprint.c (generic_emit_char):
(generic_printstr):
(val_print_string):
Use type_byte_order instead of gdbarch_byte_order.
* value.c (unpack_long):
(unpack_bits_as_long):
(unpack_value_bitfield):
(modify_field):
(pack_long):
(pack_unsigned_long):
Use type_byte_order instead of gdbarch_byte_order.
* findvar.c (unsigned_pointer_to_address):
(signed_pointer_to_address):
(unsigned_address_to_pointer):
(address_to_signed_pointer):
(default_read_var_value):
(default_value_from_register):
Use type_byte_order instead of gdbarch_byte_order.
* gnu-v3-abi.c (gnuv3_make_method_ptr):
Use type_byte_order instead of gdbarch_byte_order.
* riscv-tdep.c (riscv_print_one_register_info):
Use type_byte_order instead of gdbarch_byte_order.
gdb/testsuite/ChangeLog
2019-11-21 Peeter Joot <peeter.joot@lzlabs.com>
* gdb.base/endianity.c: New test.
* gdb.base/endianity.exp: New file.
Change-Id: I4bd98c1b4508c2d7c5a5dbb15d7b7b1cb4e667e2
2017-10-06 16:13:04 -04:00
|
|
|
|
if (type_byte_order (type) == BFD_ENDIAN_BIG)
|
2011-06-29 15:32:40 +00:00
|
|
|
|
encoding = "UTF-32BE";
|
|
|
|
|
else
|
|
|
|
|
encoding = "UTF-32LE";
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
error (_("unrecognized character type"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return encoding;
|
|
|
|
|
}
|
|
|
|
|
|
1999-04-16 01:35:26 +00:00
|
|
|
|
|
1999-07-07 20:19:36 +00:00
|
|
|
|
|
1999-04-16 01:35:26 +00:00
|
|
|
|
/* Table of operators and their precedences for printing expressions. */
|
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
const struct op_print f_language::op_print_tab[] =
|
1999-07-07 20:19:36 +00:00
|
|
|
|
{
|
|
|
|
|
{"+", BINOP_ADD, PREC_ADD, 0},
|
|
|
|
|
{"+", UNOP_PLUS, PREC_PREFIX, 0},
|
|
|
|
|
{"-", BINOP_SUB, PREC_ADD, 0},
|
|
|
|
|
{"-", UNOP_NEG, PREC_PREFIX, 0},
|
|
|
|
|
{"*", BINOP_MUL, PREC_MUL, 0},
|
|
|
|
|
{"/", BINOP_DIV, PREC_MUL, 0},
|
|
|
|
|
{"DIV", BINOP_INTDIV, PREC_MUL, 0},
|
|
|
|
|
{"MOD", BINOP_REM, PREC_MUL, 0},
|
|
|
|
|
{"=", BINOP_ASSIGN, PREC_ASSIGN, 1},
|
|
|
|
|
{".OR.", BINOP_LOGICAL_OR, PREC_LOGICAL_OR, 0},
|
|
|
|
|
{".AND.", BINOP_LOGICAL_AND, PREC_LOGICAL_AND, 0},
|
|
|
|
|
{".NOT.", UNOP_LOGICAL_NOT, PREC_PREFIX, 0},
|
|
|
|
|
{".EQ.", BINOP_EQUAL, PREC_EQUAL, 0},
|
|
|
|
|
{".NE.", BINOP_NOTEQUAL, PREC_EQUAL, 0},
|
|
|
|
|
{".LE.", BINOP_LEQ, PREC_ORDER, 0},
|
|
|
|
|
{".GE.", BINOP_GEQ, PREC_ORDER, 0},
|
|
|
|
|
{".GT.", BINOP_GTR, PREC_ORDER, 0},
|
|
|
|
|
{".LT.", BINOP_LESS, PREC_ORDER, 0},
|
|
|
|
|
{"**", UNOP_IND, PREC_PREFIX, 0},
|
|
|
|
|
{"@", BINOP_REPEAT, PREC_REPEAT, 0},
|
2015-07-31 13:19:53 -04:00
|
|
|
|
{NULL, OP_NULL, PREC_REPEAT, 0}
|
1999-04-16 01:35:26 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for the "bound" intrinsics that checks that TYPE
|
|
|
|
|
is an array. LBOUND_P is true for lower bound; this is used for
|
|
|
|
|
the error message, if any. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
fortran_require_array (struct type *type, bool lbound_p)
|
|
|
|
|
{
|
|
|
|
|
type = check_typedef (type);
|
|
|
|
|
if (type->code () != TYPE_CODE_ARRAY)
|
|
|
|
|
{
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
error (_("LBOUND can only be applied to arrays"));
|
|
|
|
|
else
|
|
|
|
|
error (_("UBOUND can only be applied to arrays"));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-09 15:46:13 +00:00
|
|
|
|
/* Create an array containing the lower bounds (when LBOUND_P is true) or
|
|
|
|
|
the upper bounds (when LBOUND_P is false) of ARRAY (which must be of
|
|
|
|
|
array type). GDBARCH is the current architecture. */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
|
|
|
|
fortran_bounds_all_dims (bool lbound_p,
|
|
|
|
|
struct gdbarch *gdbarch,
|
|
|
|
|
struct value *array)
|
|
|
|
|
{
|
|
|
|
|
type *array_type = check_typedef (value_type (array));
|
|
|
|
|
int ndimensions = calc_f77_array_dims (array_type);
|
|
|
|
|
|
|
|
|
|
/* Allocate a result value of the correct type. */
|
|
|
|
|
struct type *range
|
|
|
|
|
= create_static_range_type (nullptr,
|
|
|
|
|
builtin_type (gdbarch)->builtin_int,
|
|
|
|
|
1, ndimensions);
|
|
|
|
|
struct type *elm_type = builtin_type (gdbarch)->builtin_long_long;
|
|
|
|
|
struct type *result_type = create_array_type (nullptr, elm_type, range);
|
|
|
|
|
struct value *result = allocate_value (result_type);
|
|
|
|
|
|
|
|
|
|
/* Walk the array dimensions backwards due to the way the array will be
|
|
|
|
|
laid out in memory, the first dimension will be the most inner. */
|
|
|
|
|
LONGEST elm_len = TYPE_LENGTH (elm_type);
|
|
|
|
|
for (LONGEST dst_offset = elm_len * (ndimensions - 1);
|
|
|
|
|
dst_offset >= 0;
|
|
|
|
|
dst_offset -= elm_len)
|
|
|
|
|
{
|
|
|
|
|
LONGEST b;
|
|
|
|
|
|
|
|
|
|
/* Grab the required bound. */
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
b = f77_get_lowerbound (array_type);
|
|
|
|
|
else
|
|
|
|
|
b = f77_get_upperbound (array_type);
|
|
|
|
|
|
|
|
|
|
/* And copy the value into the result value. */
|
|
|
|
|
struct value *v = value_from_longest (elm_type, b);
|
|
|
|
|
gdb_assert (dst_offset + TYPE_LENGTH (value_type (v))
|
|
|
|
|
<= TYPE_LENGTH (value_type (result)));
|
|
|
|
|
gdb_assert (TYPE_LENGTH (value_type (v)) == elm_len);
|
|
|
|
|
value_contents_copy (result, dst_offset, v, 0, elm_len);
|
|
|
|
|
|
|
|
|
|
/* Peel another dimension of the array. */
|
|
|
|
|
array_type = TYPE_TARGET_TYPE (array_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Return the lower bound (when LBOUND_P is true) or the upper bound (when
|
|
|
|
|
LBOUND_P is false) for dimension DIM_VAL (which must be an integer) of
|
|
|
|
|
ARRAY (which must be an array). GDBARCH is the current architecture. */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
|
|
|
|
fortran_bounds_for_dimension (bool lbound_p,
|
|
|
|
|
struct gdbarch *gdbarch,
|
|
|
|
|
struct value *array,
|
|
|
|
|
struct value *dim_val)
|
|
|
|
|
{
|
|
|
|
|
/* Check the requested dimension is valid for this array. */
|
|
|
|
|
type *array_type = check_typedef (value_type (array));
|
|
|
|
|
int ndimensions = calc_f77_array_dims (array_type);
|
|
|
|
|
long dim = value_as_long (dim_val);
|
|
|
|
|
if (dim < 1 || dim > ndimensions)
|
|
|
|
|
{
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
error (_("LBOUND dimension must be from 1 to %d"), ndimensions);
|
|
|
|
|
else
|
|
|
|
|
error (_("UBOUND dimension must be from 1 to %d"), ndimensions);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The type for the result. */
|
|
|
|
|
struct type *bound_type = builtin_type (gdbarch)->builtin_long_long;
|
|
|
|
|
|
|
|
|
|
/* Walk the dimensions backwards, due to the ordering in which arrays are
|
|
|
|
|
laid out the first dimension is the most inner. */
|
|
|
|
|
for (int i = ndimensions - 1; i >= 0; --i)
|
|
|
|
|
{
|
|
|
|
|
/* If this is the requested dimension then we're done. Grab the
|
|
|
|
|
bounds and return. */
|
|
|
|
|
if (i == dim - 1)
|
|
|
|
|
{
|
|
|
|
|
LONGEST b;
|
|
|
|
|
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
b = f77_get_lowerbound (array_type);
|
|
|
|
|
else
|
|
|
|
|
b = f77_get_upperbound (array_type);
|
|
|
|
|
|
|
|
|
|
return value_from_longest (bound_type, b);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Peel off another dimension of the array. */
|
|
|
|
|
array_type = TYPE_TARGET_TYPE (array_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gdb_assert_not_reached ("failed to find matching dimension");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2020-05-07 16:27:16 +01:00
|
|
|
|
/* Return the number of dimensions for a Fortran array or string. */
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
calc_f77_array_dims (struct type *array_type)
|
|
|
|
|
{
|
|
|
|
|
int ndimen = 1;
|
|
|
|
|
struct type *tmp_type;
|
|
|
|
|
|
|
|
|
|
if ((array_type->code () == TYPE_CODE_STRING))
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if ((array_type->code () != TYPE_CODE_ARRAY))
|
|
|
|
|
error (_("Can't get dimensions for a non-array type"));
|
|
|
|
|
|
|
|
|
|
tmp_type = array_type;
|
|
|
|
|
|
|
|
|
|
while ((tmp_type = TYPE_TARGET_TYPE (tmp_type)))
|
|
|
|
|
{
|
|
|
|
|
if (tmp_type->code () == TYPE_CODE_ARRAY)
|
|
|
|
|
++ndimen;
|
|
|
|
|
}
|
|
|
|
|
return ndimen;
|
|
|
|
|
}
|
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* A class used by FORTRAN_VALUE_SUBARRAY when repacking Fortran array
|
|
|
|
|
slices. This is a base class for two alternative repacking mechanisms,
|
|
|
|
|
one for when repacking from a lazy value, and one for repacking from a
|
|
|
|
|
non-lazy (already loaded) value. */
|
|
|
|
|
class fortran_array_repacker_base_impl
|
|
|
|
|
: public fortran_array_walker_base_impl
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
/* Constructor, DEST is the value we are repacking into. */
|
|
|
|
|
fortran_array_repacker_base_impl (struct value *dest)
|
|
|
|
|
: m_dest (dest),
|
|
|
|
|
m_dest_offset (0)
|
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
|
|
/* When we start processing the inner most dimension, this is where we
|
|
|
|
|
will be creating values for each element as we load them and then copy
|
|
|
|
|
them into the M_DEST value. Set a value mark so we can free these
|
|
|
|
|
temporary values. */
|
|
|
|
|
void start_dimension (bool inner_p)
|
|
|
|
|
{
|
|
|
|
|
if (inner_p)
|
|
|
|
|
{
|
|
|
|
|
gdb_assert (m_mark == nullptr);
|
|
|
|
|
m_mark = value_mark ();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* When we finish processing the inner most dimension free all temporary
|
|
|
|
|
value that were created. */
|
|
|
|
|
void finish_dimension (bool inner_p, bool last_p)
|
|
|
|
|
{
|
|
|
|
|
if (inner_p)
|
|
|
|
|
{
|
|
|
|
|
gdb_assert (m_mark != nullptr);
|
|
|
|
|
value_free_to_mark (m_mark);
|
|
|
|
|
m_mark = nullptr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
/* Copy the contents of array element ELT into M_DEST at the next
|
|
|
|
|
available offset. */
|
|
|
|
|
void copy_element_to_dest (struct value *elt)
|
|
|
|
|
{
|
|
|
|
|
value_contents_copy (m_dest, m_dest_offset, elt, 0,
|
|
|
|
|
TYPE_LENGTH (value_type (elt)));
|
|
|
|
|
m_dest_offset += TYPE_LENGTH (value_type (elt));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The value being written to. */
|
|
|
|
|
struct value *m_dest;
|
|
|
|
|
|
|
|
|
|
/* The byte offset in M_DEST at which the next element should be
|
|
|
|
|
written. */
|
|
|
|
|
LONGEST m_dest_offset;
|
|
|
|
|
|
|
|
|
|
/* Set with a call to VALUE_MARK, and then reset after calling
|
|
|
|
|
VALUE_FREE_TO_MARK. */
|
|
|
|
|
struct value *m_mark = nullptr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* A class used by FORTRAN_VALUE_SUBARRAY when repacking Fortran array
|
|
|
|
|
slices. This class is specialised for repacking an array slice from a
|
|
|
|
|
lazy array value, as such it does not require the parent array value to
|
|
|
|
|
be loaded into GDB's memory; the parent value could be huge, while the
|
|
|
|
|
slice could be tiny. */
|
|
|
|
|
class fortran_lazy_array_repacker_impl
|
|
|
|
|
: public fortran_array_repacker_base_impl
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
/* Constructor. TYPE is the type of the slice being loaded from the
|
|
|
|
|
parent value, so this type will correctly reflect the strides required
|
|
|
|
|
to find all of the elements from the parent value. ADDRESS is the
|
|
|
|
|
address in target memory of value matching TYPE, and DEST is the value
|
|
|
|
|
we are repacking into. */
|
|
|
|
|
explicit fortran_lazy_array_repacker_impl (struct type *type,
|
|
|
|
|
CORE_ADDR address,
|
|
|
|
|
struct value *dest)
|
|
|
|
|
: fortran_array_repacker_base_impl (dest),
|
|
|
|
|
m_addr (address)
|
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
|
|
/* Create a lazy value in target memory representing a single element,
|
|
|
|
|
then load the element into GDB's memory and copy the contents into the
|
|
|
|
|
destination value. */
|
|
|
|
|
void process_element (struct type *elt_type, LONGEST elt_off, bool last_p)
|
|
|
|
|
{
|
|
|
|
|
copy_element_to_dest (value_at_lazy (elt_type, m_addr + elt_off));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
/* The address in target memory where the parent value starts. */
|
|
|
|
|
CORE_ADDR m_addr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* A class used by FORTRAN_VALUE_SUBARRAY when repacking Fortran array
|
|
|
|
|
slices. This class is specialised for repacking an array slice from a
|
|
|
|
|
previously loaded (non-lazy) array value, as such it fetches the
|
|
|
|
|
element values from the contents of the parent value. */
|
|
|
|
|
class fortran_array_repacker_impl
|
|
|
|
|
: public fortran_array_repacker_base_impl
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
/* Constructor. TYPE is the type for the array slice within the parent
|
|
|
|
|
value, as such it has stride values as required to find the elements
|
|
|
|
|
within the original parent value. ADDRESS is the address in target
|
|
|
|
|
memory of the value matching TYPE. BASE_OFFSET is the offset from
|
|
|
|
|
the start of VAL's content buffer to the start of the object of TYPE,
|
|
|
|
|
VAL is the parent object from which we are loading the value, and
|
|
|
|
|
DEST is the value into which we are repacking. */
|
|
|
|
|
explicit fortran_array_repacker_impl (struct type *type, CORE_ADDR address,
|
|
|
|
|
LONGEST base_offset,
|
|
|
|
|
struct value *val, struct value *dest)
|
|
|
|
|
: fortran_array_repacker_base_impl (dest),
|
|
|
|
|
m_base_offset (base_offset),
|
|
|
|
|
m_val (val)
|
|
|
|
|
{
|
|
|
|
|
gdb_assert (!value_lazy (val));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Extract an element of ELT_TYPE at offset (M_BASE_OFFSET + ELT_OFF)
|
|
|
|
|
from the content buffer of M_VAL then copy this extracted value into
|
|
|
|
|
the repacked destination value. */
|
|
|
|
|
void process_element (struct type *elt_type, LONGEST elt_off, bool last_p)
|
|
|
|
|
{
|
|
|
|
|
struct value *elt
|
|
|
|
|
= value_from_component (m_val, elt_type, (elt_off + m_base_offset));
|
|
|
|
|
copy_element_to_dest (elt);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
/* The offset into the content buffer of M_VAL to the start of the slice
|
|
|
|
|
being extracted. */
|
|
|
|
|
LONGEST m_base_offset;
|
|
|
|
|
|
|
|
|
|
/* The parent value from which we are extracting a slice. */
|
|
|
|
|
struct value *m_val;
|
|
|
|
|
};
|
|
|
|
|
|
2020-05-07 16:27:16 +01:00
|
|
|
|
/* Called from evaluate_subexp_standard to perform array indexing, and
|
|
|
|
|
sub-range extraction, for Fortran. As well as arrays this function
|
|
|
|
|
also handles strings as they can be treated like arrays of characters.
|
|
|
|
|
ARRAY is the array or string being accessed. EXP, POS, and NOSIDE are
|
|
|
|
|
as for evaluate_subexp_standard, and NARGS is the number of arguments
|
|
|
|
|
in this access (e.g. 'array (1,2,3)' would be NARGS 3). */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
|
|
|
|
fortran_value_subarray (struct value *array, struct expression *exp,
|
|
|
|
|
int *pos, int nargs, enum noside noside)
|
|
|
|
|
{
|
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 16:45:59 +01:00
|
|
|
|
type *original_array_type = check_typedef (value_type (array));
|
|
|
|
|
bool is_string_p = original_array_type->code () == TYPE_CODE_STRING;
|
|
|
|
|
|
|
|
|
|
/* Perform checks for ARRAY not being available. The somewhat overly
|
|
|
|
|
complex logic here is just to keep backward compatibility with the
|
|
|
|
|
errors that we used to get before FORTRAN_VALUE_SUBARRAY was
|
|
|
|
|
rewritten. Maybe a future task would streamline the error messages we
|
|
|
|
|
get here, and update all the expected test results. */
|
|
|
|
|
if (exp->elts[*pos].opcode != OP_RANGE)
|
|
|
|
|
{
|
|
|
|
|
if (type_not_associated (original_array_type))
|
|
|
|
|
error (_("no such vector element (vector not associated)"));
|
|
|
|
|
else if (type_not_allocated (original_array_type))
|
|
|
|
|
error (_("no such vector element (vector not allocated)"));
|
|
|
|
|
}
|
|
|
|
|
else
|
2020-05-07 16:27:16 +01:00
|
|
|
|
{
|
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 16:45:59 +01:00
|
|
|
|
if (type_not_associated (original_array_type))
|
|
|
|
|
error (_("array not associated"));
|
|
|
|
|
else if (type_not_allocated (original_array_type))
|
|
|
|
|
error (_("array not allocated"));
|
2020-05-07 16:27:16 +01:00
|
|
|
|
}
|
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* First check that the number of dimensions in the type we are slicing
|
|
|
|
|
matches the number of arguments we were passed. */
|
|
|
|
|
int ndimensions = calc_f77_array_dims (original_array_type);
|
|
|
|
|
if (nargs != ndimensions)
|
|
|
|
|
error (_("Wrong number of subscripts"));
|
|
|
|
|
|
|
|
|
|
/* This will be initialised below with the type of the elements held in
|
|
|
|
|
ARRAY. */
|
|
|
|
|
struct type *inner_element_type;
|
|
|
|
|
|
|
|
|
|
/* Extract the types of each array dimension from the original array
|
|
|
|
|
type. We need these available so we can fill in the default upper and
|
|
|
|
|
lower bounds if the user requested slice doesn't provide that
|
|
|
|
|
information. Additionally unpacking the dimensions like this gives us
|
|
|
|
|
the inner element type. */
|
|
|
|
|
std::vector<struct type *> dim_types;
|
|
|
|
|
{
|
|
|
|
|
dim_types.reserve (ndimensions);
|
|
|
|
|
struct type *type = original_array_type;
|
|
|
|
|
for (int i = 0; i < ndimensions; ++i)
|
|
|
|
|
{
|
|
|
|
|
dim_types.push_back (type);
|
|
|
|
|
type = TYPE_TARGET_TYPE (type);
|
|
|
|
|
}
|
|
|
|
|
/* TYPE is now the inner element type of the array, we start the new
|
|
|
|
|
array slice off as this type, then as we process the requested slice
|
|
|
|
|
(from the user) we wrap new types around this to build up the final
|
|
|
|
|
slice type. */
|
|
|
|
|
inner_element_type = type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* As we analyse the new slice type we need to understand if the data
|
|
|
|
|
being referenced is contiguous. Do decide this we must track the size
|
|
|
|
|
of an element at each dimension of the new slice array. Initially the
|
|
|
|
|
elements of the inner most dimension of the array are the same inner
|
|
|
|
|
most elements as the original ARRAY. */
|
|
|
|
|
LONGEST slice_element_size = TYPE_LENGTH (inner_element_type);
|
|
|
|
|
|
|
|
|
|
/* Start off assuming all data is contiguous, this will be set to false
|
|
|
|
|
if access to any dimension results in non-contiguous data. */
|
|
|
|
|
bool is_all_contiguous = true;
|
|
|
|
|
|
|
|
|
|
/* The TOTAL_OFFSET is the distance in bytes from the start of the
|
|
|
|
|
original ARRAY to the start of the new slice. This is calculated as
|
|
|
|
|
we process the information from the user. */
|
|
|
|
|
LONGEST total_offset = 0;
|
|
|
|
|
|
|
|
|
|
/* A structure representing information about each dimension of the
|
|
|
|
|
resulting slice. */
|
|
|
|
|
struct slice_dim
|
|
|
|
|
{
|
|
|
|
|
/* Constructor. */
|
|
|
|
|
slice_dim (LONGEST l, LONGEST h, LONGEST s, struct type *idx)
|
|
|
|
|
: low (l),
|
|
|
|
|
high (h),
|
|
|
|
|
stride (s),
|
|
|
|
|
index (idx)
|
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
|
|
/* The low bound for this dimension of the slice. */
|
|
|
|
|
LONGEST low;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* The high bound for this dimension of the slice. */
|
|
|
|
|
LONGEST high;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* The byte stride for this dimension of the slice. */
|
|
|
|
|
LONGEST stride;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
struct type *index;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* The dimensions of the resulting slice. */
|
|
|
|
|
std::vector<slice_dim> slice_dims;
|
|
|
|
|
|
|
|
|
|
/* Process the incoming arguments. These arguments are in the reverse
|
|
|
|
|
order to the array dimensions, that is the first argument refers to
|
|
|
|
|
the last array dimension. */
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
debug_printf ("Processing array access:\n");
|
|
|
|
|
for (int i = 0; i < nargs; ++i)
|
|
|
|
|
{
|
|
|
|
|
/* For each dimension of the array the user will have either provided
|
|
|
|
|
a ranged access with optional lower bound, upper bound, and
|
|
|
|
|
stride, or the user will have supplied a single index. */
|
|
|
|
|
struct type *dim_type = dim_types[ndimensions - (i + 1)];
|
|
|
|
|
if (exp->elts[*pos].opcode == OP_RANGE)
|
|
|
|
|
{
|
|
|
|
|
int pc = (*pos) + 1;
|
|
|
|
|
enum range_flag range_flag = (enum range_flag) exp->elts[pc].longconst;
|
|
|
|
|
*pos += 3;
|
|
|
|
|
|
|
|
|
|
LONGEST low, high, stride;
|
|
|
|
|
low = high = stride = 0;
|
|
|
|
|
|
|
|
|
|
if ((range_flag & RANGE_LOW_BOUND_DEFAULT) == 0)
|
|
|
|
|
low = value_as_long (evaluate_subexp (nullptr, exp, pos, noside));
|
|
|
|
|
else
|
|
|
|
|
low = f77_get_lowerbound (dim_type);
|
|
|
|
|
if ((range_flag & RANGE_HIGH_BOUND_DEFAULT) == 0)
|
|
|
|
|
high = value_as_long (evaluate_subexp (nullptr, exp, pos, noside));
|
|
|
|
|
else
|
|
|
|
|
high = f77_get_upperbound (dim_type);
|
|
|
|
|
if ((range_flag & RANGE_HAS_STRIDE) == RANGE_HAS_STRIDE)
|
|
|
|
|
stride = value_as_long (evaluate_subexp (nullptr, exp, pos, noside));
|
|
|
|
|
else
|
|
|
|
|
stride = 1;
|
|
|
|
|
|
|
|
|
|
if (stride == 0)
|
|
|
|
|
error (_("stride must not be 0"));
|
|
|
|
|
|
|
|
|
|
/* Get information about this dimension in the original ARRAY. */
|
|
|
|
|
struct type *target_type = TYPE_TARGET_TYPE (dim_type);
|
|
|
|
|
struct type *index_type = dim_type->index_type ();
|
|
|
|
|
LONGEST lb = f77_get_lowerbound (dim_type);
|
|
|
|
|
LONGEST ub = f77_get_upperbound (dim_type);
|
|
|
|
|
LONGEST sd = index_type->bit_stride ();
|
|
|
|
|
if (sd == 0)
|
|
|
|
|
sd = TYPE_LENGTH (target_type) * 8;
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("|-> Range access\n");
|
|
|
|
|
std::string str = type_to_string (dim_type);
|
|
|
|
|
debug_printf ("| |-> Type: %s\n", str.c_str ());
|
|
|
|
|
debug_printf ("| |-> Array:\n");
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n", plongest (lb));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n", plongest (ub));
|
|
|
|
|
debug_printf ("| | |-> Bit stride: %s\n", plongest (sd));
|
|
|
|
|
debug_printf ("| | |-> Byte stride: %s\n", plongest (sd / 8));
|
|
|
|
|
debug_printf ("| | |-> Type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (dim_type)));
|
|
|
|
|
debug_printf ("| | '-> Target type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (target_type)));
|
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 16:45:59 +01:00
|
|
|
|
debug_printf ("| |-> Accessing:\n");
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n",
|
|
|
|
|
plongest (low));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n",
|
|
|
|
|
plongest (high));
|
|
|
|
|
debug_printf ("| | '-> Element stride: %s\n",
|
|
|
|
|
plongest (stride));
|
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 16:45:59 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check the user hasn't asked for something invalid. */
|
|
|
|
|
if (high > ub || low < lb)
|
|
|
|
|
error (_("array subscript out of bounds"));
|
|
|
|
|
|
|
|
|
|
/* Calculate what this dimension of the new slice array will look
|
|
|
|
|
like. OFFSET is the byte offset from the start of the
|
|
|
|
|
previous (more outer) dimension to the start of this
|
|
|
|
|
dimension. E_COUNT is the number of elements in this
|
|
|
|
|
dimension. REMAINDER is the number of elements remaining
|
|
|
|
|
between the last included element and the upper bound. For
|
|
|
|
|
example an access '1:6:2' will include elements 1, 3, 5 and
|
|
|
|
|
have a remainder of 1 (element #6). */
|
|
|
|
|
LONGEST lowest = std::min (low, high);
|
|
|
|
|
LONGEST offset = (sd / 8) * (lowest - lb);
|
|
|
|
|
LONGEST e_count = std::abs (high - low) + 1;
|
|
|
|
|
e_count = (e_count + (std::abs (stride) - 1)) / std::abs (stride);
|
|
|
|
|
LONGEST new_low = 1;
|
|
|
|
|
LONGEST new_high = new_low + e_count - 1;
|
|
|
|
|
LONGEST new_stride = (sd * stride) / 8;
|
|
|
|
|
LONGEST last_elem = low + ((e_count - 1) * stride);
|
|
|
|
|
LONGEST remainder = high - last_elem;
|
|
|
|
|
if (low > high)
|
|
|
|
|
{
|
|
|
|
|
offset += std::abs (remainder) * TYPE_LENGTH (target_type);
|
|
|
|
|
if (stride > 0)
|
|
|
|
|
error (_("incorrect stride and boundary combination"));
|
|
|
|
|
}
|
|
|
|
|
else if (stride < 0)
|
|
|
|
|
error (_("incorrect stride and boundary combination"));
|
|
|
|
|
|
|
|
|
|
/* Is the data within this dimension contiguous? It is if the
|
|
|
|
|
newly computed stride is the same size as a single element of
|
|
|
|
|
this dimension. */
|
|
|
|
|
bool is_dim_contiguous = (new_stride == slice_element_size);
|
|
|
|
|
is_all_contiguous &= is_dim_contiguous;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("| '-> Results:\n");
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf ("| |-> Offset = %s\n", plongest (offset));
|
|
|
|
|
debug_printf ("| |-> Elements = %s\n", plongest (e_count));
|
|
|
|
|
debug_printf ("| |-> Low bound = %s\n", plongest (new_low));
|
|
|
|
|
debug_printf ("| |-> High bound = %s\n",
|
|
|
|
|
plongest (new_high));
|
|
|
|
|
debug_printf ("| |-> Byte stride = %s\n",
|
|
|
|
|
plongest (new_stride));
|
|
|
|
|
debug_printf ("| |-> Last element = %s\n",
|
|
|
|
|
plongest (last_elem));
|
|
|
|
|
debug_printf ("| |-> Remainder = %s\n",
|
|
|
|
|
plongest (remainder));
|
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 16:45:59 +01:00
|
|
|
|
debug_printf ("| '-> Contiguous = %s\n",
|
|
|
|
|
(is_dim_contiguous ? "Yes" : "No"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Figure out how big (in bytes) an element of this dimension of
|
|
|
|
|
the new array slice will be. */
|
|
|
|
|
slice_element_size = std::abs (new_stride * e_count);
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
slice_dims.emplace_back (new_low, new_high, new_stride,
|
|
|
|
|
index_type);
|
|
|
|
|
|
|
|
|
|
/* Update the total offset. */
|
|
|
|
|
total_offset += offset;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* There is a single index for this dimension. */
|
|
|
|
|
LONGEST index
|
|
|
|
|
= value_as_long (evaluate_subexp_with_coercion (exp, pos, noside));
|
|
|
|
|
|
|
|
|
|
/* Get information about this dimension in the original ARRAY. */
|
|
|
|
|
struct type *target_type = TYPE_TARGET_TYPE (dim_type);
|
|
|
|
|
struct type *index_type = dim_type->index_type ();
|
|
|
|
|
LONGEST lb = f77_get_lowerbound (dim_type);
|
|
|
|
|
LONGEST ub = f77_get_upperbound (dim_type);
|
|
|
|
|
LONGEST sd = index_type->bit_stride () / 8;
|
|
|
|
|
if (sd == 0)
|
|
|
|
|
sd = TYPE_LENGTH (target_type);
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("|-> Index access\n");
|
|
|
|
|
std::string str = type_to_string (dim_type);
|
|
|
|
|
debug_printf ("| |-> Type: %s\n", str.c_str ());
|
|
|
|
|
debug_printf ("| |-> Array:\n");
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n", plongest (lb));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n", plongest (ub));
|
|
|
|
|
debug_printf ("| | |-> Byte stride: %s\n", plongest (sd));
|
|
|
|
|
debug_printf ("| | |-> Type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (dim_type)));
|
|
|
|
|
debug_printf ("| | '-> Target type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (target_type)));
|
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 16:45:59 +01:00
|
|
|
|
debug_printf ("| '-> Accessing:\n");
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf ("| '-> Index: %s\n",
|
|
|
|
|
plongest (index));
|
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 16:45:59 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If the array has actual content then check the index is in
|
|
|
|
|
bounds. An array without content (an unbound array) doesn't
|
|
|
|
|
have a known upper bound, so don't error check in that
|
|
|
|
|
situation. */
|
|
|
|
|
if (index < lb
|
|
|
|
|
|| (dim_type->index_type ()->bounds ()->high.kind () != PROP_UNDEFINED
|
|
|
|
|
&& index > ub)
|
|
|
|
|
|| (VALUE_LVAL (array) != lval_memory
|
|
|
|
|
&& dim_type->index_type ()->bounds ()->high.kind () == PROP_UNDEFINED))
|
|
|
|
|
{
|
|
|
|
|
if (type_not_associated (dim_type))
|
|
|
|
|
error (_("no such vector element (vector not associated)"));
|
|
|
|
|
else if (type_not_allocated (dim_type))
|
|
|
|
|
error (_("no such vector element (vector not allocated)"));
|
|
|
|
|
else
|
|
|
|
|
error (_("no such vector element"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Calculate using the type stride, not the target type size. */
|
|
|
|
|
LONGEST offset = sd * (index - lb);
|
|
|
|
|
total_offset += offset;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return array;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* Build a type that represents the new array slice in the target memory
|
|
|
|
|
of the original ARRAY, this type makes use of strides to correctly
|
|
|
|
|
find only those elements that are part of the new slice. */
|
|
|
|
|
struct type *array_slice_type = inner_element_type;
|
|
|
|
|
for (const auto &d : slice_dims)
|
2020-05-07 16:27:16 +01:00
|
|
|
|
{
|
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 16:45:59 +01:00
|
|
|
|
/* Create the range. */
|
|
|
|
|
dynamic_prop p_low, p_high, p_stride;
|
|
|
|
|
|
|
|
|
|
p_low.set_const_val (d.low);
|
|
|
|
|
p_high.set_const_val (d.high);
|
|
|
|
|
p_stride.set_const_val (d.stride);
|
|
|
|
|
|
|
|
|
|
struct type *new_range
|
|
|
|
|
= create_range_type_with_stride ((struct type *) NULL,
|
|
|
|
|
TYPE_TARGET_TYPE (d.index),
|
|
|
|
|
&p_low, &p_high, 0, &p_stride,
|
|
|
|
|
true);
|
|
|
|
|
array_slice_type
|
|
|
|
|
= create_array_type (nullptr, array_slice_type, new_range);
|
|
|
|
|
}
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("'-> Final result:\n");
|
|
|
|
|
debug_printf (" |-> Type: %s\n",
|
|
|
|
|
type_to_string (array_slice_type).c_str ());
|
2020-11-19 11:31:34 -05:00
|
|
|
|
debug_printf (" |-> Total offset: %s\n",
|
|
|
|
|
plongest (total_offset));
|
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 16:45:59 +01:00
|
|
|
|
debug_printf (" |-> Base address: %s\n",
|
|
|
|
|
core_addr_to_string (value_address (array)));
|
|
|
|
|
debug_printf (" '-> Contiguous = %s\n",
|
|
|
|
|
(is_all_contiguous ? "Yes" : "No"));
|
2020-05-07 16:27:16 +01:00
|
|
|
|
}
|
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* Should we repack this array slice? */
|
|
|
|
|
if (!is_all_contiguous && (repack_array_slices || is_string_p))
|
2020-05-07 16:27:16 +01:00
|
|
|
|
{
|
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 16:45:59 +01:00
|
|
|
|
/* Build a type for the repacked slice. */
|
|
|
|
|
struct type *repacked_array_type = inner_element_type;
|
|
|
|
|
for (const auto &d : slice_dims)
|
|
|
|
|
{
|
|
|
|
|
/* Create the range. */
|
|
|
|
|
dynamic_prop p_low, p_high, p_stride;
|
|
|
|
|
|
|
|
|
|
p_low.set_const_val (d.low);
|
|
|
|
|
p_high.set_const_val (d.high);
|
|
|
|
|
p_stride.set_const_val (TYPE_LENGTH (repacked_array_type));
|
|
|
|
|
|
|
|
|
|
struct type *new_range
|
|
|
|
|
= create_range_type_with_stride ((struct type *) NULL,
|
|
|
|
|
TYPE_TARGET_TYPE (d.index),
|
|
|
|
|
&p_low, &p_high, 0, &p_stride,
|
|
|
|
|
true);
|
|
|
|
|
repacked_array_type
|
|
|
|
|
= create_array_type (nullptr, repacked_array_type, new_range);
|
|
|
|
|
}
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* Now copy the elements from the original ARRAY into the packed
|
|
|
|
|
array value DEST. */
|
|
|
|
|
struct value *dest = allocate_value (repacked_array_type);
|
|
|
|
|
if (value_lazy (array)
|
|
|
|
|
|| (total_offset + TYPE_LENGTH (array_slice_type)
|
|
|
|
|
> TYPE_LENGTH (check_typedef (value_type (array)))))
|
|
|
|
|
{
|
|
|
|
|
fortran_array_walker<fortran_lazy_array_repacker_impl> p
|
|
|
|
|
(array_slice_type, value_address (array) + total_offset, dest);
|
|
|
|
|
p.walk ();
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
fortran_array_walker<fortran_array_repacker_impl> p
|
|
|
|
|
(array_slice_type, value_address (array) + total_offset,
|
|
|
|
|
total_offset, array, dest);
|
|
|
|
|
p.walk ();
|
|
|
|
|
}
|
|
|
|
|
array = dest;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (VALUE_LVAL (array) == lval_memory)
|
|
|
|
|
{
|
|
|
|
|
/* If the value we're taking a slice from is not yet loaded, or
|
|
|
|
|
the requested slice is outside the values content range then
|
|
|
|
|
just create a new lazy value pointing at the memory where the
|
|
|
|
|
contents we're looking for exist. */
|
|
|
|
|
if (value_lazy (array)
|
|
|
|
|
|| (total_offset + TYPE_LENGTH (array_slice_type)
|
|
|
|
|
> TYPE_LENGTH (check_typedef (value_type (array)))))
|
|
|
|
|
array = value_at_lazy (array_slice_type,
|
|
|
|
|
value_address (array) + total_offset);
|
|
|
|
|
else
|
|
|
|
|
array = value_from_contents_and_address (array_slice_type,
|
|
|
|
|
(value_contents (array)
|
|
|
|
|
+ total_offset),
|
|
|
|
|
(value_address (array)
|
|
|
|
|
+ total_offset));
|
|
|
|
|
}
|
|
|
|
|
else if (!value_lazy (array))
|
2021-01-07 17:13:21 +00:00
|
|
|
|
array = value_from_component (array, array_slice_type, total_offset);
|
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 16:45:59 +01:00
|
|
|
|
else
|
|
|
|
|
error (_("cannot subscript arrays that are not in memory"));
|
2020-05-07 16:27:16 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return array;
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
/* Evaluate FORTRAN_ASSOCIATED expressions. Both GDBARCH and LANG are
|
|
|
|
|
extracted from the expression being evaluated. POINTER is the required
|
|
|
|
|
first argument to the 'associated' keyword, and TARGET is the optional
|
|
|
|
|
second argument, this will be nullptr if the user only passed one
|
|
|
|
|
argument to their use of 'associated'. */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
|
|
|
|
fortran_associated (struct gdbarch *gdbarch, const language_defn *lang,
|
|
|
|
|
struct value *pointer, struct value *target = nullptr)
|
|
|
|
|
{
|
|
|
|
|
struct type *result_type = language_bool_type (lang, gdbarch);
|
|
|
|
|
|
|
|
|
|
/* All Fortran pointers should have the associated property, this is
|
|
|
|
|
how we know the pointer is pointing at something or not. */
|
|
|
|
|
struct type *pointer_type = check_typedef (value_type (pointer));
|
|
|
|
|
if (TYPE_ASSOCIATED_PROP (pointer_type) == nullptr
|
|
|
|
|
&& pointer_type->code () != TYPE_CODE_PTR)
|
|
|
|
|
error (_("ASSOCIATED can only be applied to pointers"));
|
|
|
|
|
|
|
|
|
|
/* Get an address from POINTER. Fortran (or at least gfortran) models
|
|
|
|
|
array pointers as arrays with a dynamic data address, so we need to
|
|
|
|
|
use two approaches here, for real pointers we take the contents of the
|
|
|
|
|
pointer as an address. For non-pointers we take the address of the
|
|
|
|
|
content. */
|
|
|
|
|
CORE_ADDR pointer_addr;
|
|
|
|
|
if (pointer_type->code () == TYPE_CODE_PTR)
|
|
|
|
|
pointer_addr = value_as_address (pointer);
|
|
|
|
|
else
|
|
|
|
|
pointer_addr = value_address (pointer);
|
|
|
|
|
|
|
|
|
|
/* The single argument case, is POINTER associated with anything? */
|
|
|
|
|
if (target == nullptr)
|
|
|
|
|
{
|
|
|
|
|
bool is_associated = false;
|
|
|
|
|
|
|
|
|
|
/* If POINTER is an actual pointer and doesn't have an associated
|
|
|
|
|
property then we need to figure out whether this pointer is
|
|
|
|
|
associated by looking at the value of the pointer itself. We make
|
|
|
|
|
the assumption that a non-associated pointer will be set to 0.
|
|
|
|
|
This is probably true for most targets, but might not be true for
|
|
|
|
|
everyone. */
|
|
|
|
|
if (pointer_type->code () == TYPE_CODE_PTR
|
|
|
|
|
&& TYPE_ASSOCIATED_PROP (pointer_type) == nullptr)
|
|
|
|
|
is_associated = (pointer_addr != 0);
|
|
|
|
|
else
|
|
|
|
|
is_associated = !type_not_associated (pointer_type);
|
|
|
|
|
return value_from_longest (result_type, is_associated ? 1 : 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The two argument case, is POINTER associated with TARGET? */
|
|
|
|
|
|
|
|
|
|
struct type *target_type = check_typedef (value_type (target));
|
|
|
|
|
|
|
|
|
|
struct type *pointer_target_type;
|
|
|
|
|
if (pointer_type->code () == TYPE_CODE_PTR)
|
|
|
|
|
pointer_target_type = TYPE_TARGET_TYPE (pointer_type);
|
|
|
|
|
else
|
|
|
|
|
pointer_target_type = pointer_type;
|
|
|
|
|
|
|
|
|
|
struct type *target_target_type;
|
|
|
|
|
if (target_type->code () == TYPE_CODE_PTR)
|
|
|
|
|
target_target_type = TYPE_TARGET_TYPE (target_type);
|
|
|
|
|
else
|
|
|
|
|
target_target_type = target_type;
|
|
|
|
|
|
|
|
|
|
if (pointer_target_type->code () != target_target_type->code ()
|
|
|
|
|
|| (pointer_target_type->code () != TYPE_CODE_ARRAY
|
|
|
|
|
&& (TYPE_LENGTH (pointer_target_type)
|
|
|
|
|
!= TYPE_LENGTH (target_target_type))))
|
|
|
|
|
error (_("arguments to associated must be of same type and kind"));
|
|
|
|
|
|
|
|
|
|
/* If TARGET is not in memory, or the original pointer is specifically
|
|
|
|
|
known to be not associated with anything, then the answer is obviously
|
|
|
|
|
false. Alternatively, if POINTER is an actual pointer and has no
|
|
|
|
|
associated property, then we have to check if its associated by
|
|
|
|
|
looking the value of the pointer itself. We make the assumption that
|
|
|
|
|
a non-associated pointer will be set to 0. This is probably true for
|
|
|
|
|
most targets, but might not be true for everyone. */
|
|
|
|
|
if (value_lval_const (target) != lval_memory
|
|
|
|
|
|| type_not_associated (pointer_type)
|
|
|
|
|
|| (TYPE_ASSOCIATED_PROP (pointer_type) == nullptr
|
|
|
|
|
&& pointer_type->code () == TYPE_CODE_PTR
|
|
|
|
|
&& pointer_addr == 0))
|
|
|
|
|
return value_from_longest (result_type, 0);
|
|
|
|
|
|
|
|
|
|
/* See the comment for POINTER_ADDR above. */
|
|
|
|
|
CORE_ADDR target_addr;
|
|
|
|
|
if (target_type->code () == TYPE_CODE_PTR)
|
|
|
|
|
target_addr = value_as_address (target);
|
|
|
|
|
else
|
|
|
|
|
target_addr = value_address (target);
|
|
|
|
|
|
|
|
|
|
/* Wrap the following checks inside a do { ... } while (false) loop so
|
|
|
|
|
that we can use `break' to jump out of the loop. */
|
|
|
|
|
bool is_associated = false;
|
|
|
|
|
do
|
|
|
|
|
{
|
|
|
|
|
/* If the addresses are different then POINTER is definitely not
|
|
|
|
|
pointing at TARGET. */
|
|
|
|
|
if (pointer_addr != target_addr)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/* If POINTER is a real pointer (i.e. not an array pointer, which are
|
|
|
|
|
implemented as arrays with a dynamic content address), then this
|
|
|
|
|
is all the checking that is needed. */
|
|
|
|
|
if (pointer_type->code () == TYPE_CODE_PTR)
|
|
|
|
|
{
|
|
|
|
|
is_associated = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We have an array pointer. Check the number of dimensions. */
|
|
|
|
|
int pointer_dims = calc_f77_array_dims (pointer_type);
|
|
|
|
|
int target_dims = calc_f77_array_dims (target_type);
|
|
|
|
|
if (pointer_dims != target_dims)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/* Now check that every dimension has the same upper bound, lower
|
|
|
|
|
bound, and stride value. */
|
|
|
|
|
int dim = 0;
|
|
|
|
|
while (dim < pointer_dims)
|
|
|
|
|
{
|
|
|
|
|
LONGEST pointer_lowerbound, pointer_upperbound, pointer_stride;
|
|
|
|
|
LONGEST target_lowerbound, target_upperbound, target_stride;
|
|
|
|
|
|
|
|
|
|
pointer_type = check_typedef (pointer_type);
|
|
|
|
|
target_type = check_typedef (target_type);
|
|
|
|
|
|
|
|
|
|
struct type *pointer_range = pointer_type->index_type ();
|
|
|
|
|
struct type *target_range = target_type->index_type ();
|
|
|
|
|
|
|
|
|
|
if (!get_discrete_bounds (pointer_range, &pointer_lowerbound,
|
|
|
|
|
&pointer_upperbound))
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (!get_discrete_bounds (target_range, &target_lowerbound,
|
|
|
|
|
&target_upperbound))
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (pointer_lowerbound != target_lowerbound
|
|
|
|
|
|| pointer_upperbound != target_upperbound)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/* Figure out the stride (in bits) for both pointer and target.
|
|
|
|
|
If either doesn't have a stride then we take the element size,
|
|
|
|
|
but we need to convert to bits (hence the * 8). */
|
|
|
|
|
pointer_stride = pointer_range->bounds ()->bit_stride ();
|
|
|
|
|
if (pointer_stride == 0)
|
|
|
|
|
pointer_stride
|
|
|
|
|
= type_length_units (check_typedef
|
|
|
|
|
(TYPE_TARGET_TYPE (pointer_type))) * 8;
|
|
|
|
|
target_stride = target_range->bounds ()->bit_stride ();
|
|
|
|
|
if (target_stride == 0)
|
|
|
|
|
target_stride
|
|
|
|
|
= type_length_units (check_typedef
|
|
|
|
|
(TYPE_TARGET_TYPE (target_type))) * 8;
|
|
|
|
|
if (pointer_stride != target_stride)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
++dim;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (dim < pointer_dims)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
is_associated = true;
|
|
|
|
|
}
|
|
|
|
|
while (false);
|
|
|
|
|
|
|
|
|
|
return value_from_longest (result_type, is_associated ? 1 : 0);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
|
|
|
|
eval_op_f_associated (struct type *expect_type,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside,
|
|
|
|
|
enum exp_opcode opcode,
|
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
return fortran_associated (exp->gdbarch, exp->language_defn, arg1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct value *
|
|
|
|
|
eval_op_f_associated (struct type *expect_type,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside,
|
|
|
|
|
enum exp_opcode opcode,
|
|
|
|
|
struct value *arg1,
|
|
|
|
|
struct value *arg2)
|
|
|
|
|
{
|
|
|
|
|
return fortran_associated (exp->gdbarch, exp->language_defn, arg1, arg2);
|
|
|
|
|
}
|
2021-02-24 12:50:00 +00:00
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for UNOP_ABS. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_abs (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
switch (type->code ())
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_FLT:
|
|
|
|
|
{
|
|
|
|
|
double d
|
|
|
|
|
= fabs (target_float_to_host_double (value_contents (arg1),
|
|
|
|
|
value_type (arg1)));
|
|
|
|
|
return value_from_host_double (type, d);
|
|
|
|
|
}
|
|
|
|
|
case TYPE_CODE_INT:
|
|
|
|
|
{
|
|
|
|
|
LONGEST l = value_as_long (arg1);
|
|
|
|
|
l = llabs (l);
|
|
|
|
|
return value_from_longest (type, l);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
error (_("ABS of type %s not supported"), TYPE_SAFE_NAME (type));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for BINOP_MOD. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_mod (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1, struct value *arg2)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
if (type->code () != value_type (arg2)->code ())
|
|
|
|
|
error (_("non-matching types for parameters to MOD ()"));
|
|
|
|
|
switch (type->code ())
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_FLT:
|
|
|
|
|
{
|
|
|
|
|
double d1
|
|
|
|
|
= target_float_to_host_double (value_contents (arg1),
|
|
|
|
|
value_type (arg1));
|
|
|
|
|
double d2
|
|
|
|
|
= target_float_to_host_double (value_contents (arg2),
|
|
|
|
|
value_type (arg2));
|
|
|
|
|
double d3 = fmod (d1, d2);
|
|
|
|
|
return value_from_host_double (type, d3);
|
|
|
|
|
}
|
|
|
|
|
case TYPE_CODE_INT:
|
|
|
|
|
{
|
|
|
|
|
LONGEST v1 = value_as_long (arg1);
|
|
|
|
|
LONGEST v2 = value_as_long (arg2);
|
|
|
|
|
if (v2 == 0)
|
|
|
|
|
error (_("calling MOD (N, 0) is undefined"));
|
|
|
|
|
LONGEST v3 = v1 - (v1 / v2) * v2;
|
|
|
|
|
return value_from_longest (value_type (arg1), v3);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
error (_("MOD of type %s not supported"), TYPE_SAFE_NAME (type));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for UNOP_FORTRAN_CEILING. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_ceil (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
if (type->code () != TYPE_CODE_FLT)
|
|
|
|
|
error (_("argument to CEILING must be of type float"));
|
|
|
|
|
double val
|
|
|
|
|
= target_float_to_host_double (value_contents (arg1),
|
|
|
|
|
value_type (arg1));
|
|
|
|
|
val = ceil (val);
|
|
|
|
|
return value_from_host_double (type, val);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for UNOP_FORTRAN_FLOOR. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_floor (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
if (type->code () != TYPE_CODE_FLT)
|
|
|
|
|
error (_("argument to FLOOR must be of type float"));
|
|
|
|
|
double val
|
|
|
|
|
= target_float_to_host_double (value_contents (arg1),
|
|
|
|
|
value_type (arg1));
|
|
|
|
|
val = floor (val);
|
|
|
|
|
return value_from_host_double (type, val);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for BINOP_FORTRAN_MODULO. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_modulo (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1, struct value *arg2)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
if (type->code () != value_type (arg2)->code ())
|
|
|
|
|
error (_("non-matching types for parameters to MODULO ()"));
|
|
|
|
|
/* MODULO(A, P) = A - FLOOR (A / P) * P */
|
|
|
|
|
switch (type->code ())
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_INT:
|
|
|
|
|
{
|
|
|
|
|
LONGEST a = value_as_long (arg1);
|
|
|
|
|
LONGEST p = value_as_long (arg2);
|
|
|
|
|
LONGEST result = a - (a / p) * p;
|
|
|
|
|
if (result != 0 && (a < 0) != (p < 0))
|
|
|
|
|
result += p;
|
|
|
|
|
return value_from_longest (value_type (arg1), result);
|
|
|
|
|
}
|
|
|
|
|
case TYPE_CODE_FLT:
|
|
|
|
|
{
|
|
|
|
|
double a
|
|
|
|
|
= target_float_to_host_double (value_contents (arg1),
|
|
|
|
|
value_type (arg1));
|
|
|
|
|
double p
|
|
|
|
|
= target_float_to_host_double (value_contents (arg2),
|
|
|
|
|
value_type (arg2));
|
|
|
|
|
double result = fmod (a, p);
|
|
|
|
|
if (result != 0 && (a < 0.0) != (p < 0.0))
|
|
|
|
|
result += p;
|
|
|
|
|
return value_from_host_double (type, result);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
error (_("MODULO of type %s not supported"), TYPE_SAFE_NAME (type));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for BINOP_FORTRAN_CMPLX. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_cmplx (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1, struct value *arg2)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
struct type *type = builtin_f_type(exp->gdbarch)->builtin_complex_s16;
|
|
|
|
|
return value_literal_complex (arg1, arg2, type);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for UNOP_FORTRAN_KIND. */
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *
|
2021-03-08 07:27:57 -07:00
|
|
|
|
eval_op_f_kind (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
enum exp_opcode opcode,
|
2021-03-08 07:27:57 -07:00
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
struct type *type = value_type (arg1);
|
|
|
|
|
|
|
|
|
|
switch (type->code ())
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_STRUCT:
|
|
|
|
|
case TYPE_CODE_UNION:
|
|
|
|
|
case TYPE_CODE_MODULE:
|
|
|
|
|
case TYPE_CODE_FUNC:
|
|
|
|
|
error (_("argument to kind must be an intrinsic type"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!TYPE_TARGET_TYPE (type))
|
|
|
|
|
return value_from_longest (builtin_type (exp->gdbarch)->builtin_int,
|
|
|
|
|
TYPE_LENGTH (type));
|
|
|
|
|
return value_from_longest (builtin_type (exp->gdbarch)->builtin_int,
|
|
|
|
|
TYPE_LENGTH (TYPE_TARGET_TYPE (type)));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* A helper function for UNOP_FORTRAN_ALLOCATED. */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
|
|
|
|
eval_op_f_allocated (struct type *expect_type, struct expression *exp,
|
|
|
|
|
enum noside noside, enum exp_opcode op,
|
|
|
|
|
struct value *arg1)
|
|
|
|
|
{
|
|
|
|
|
struct type *type = check_typedef (value_type (arg1));
|
|
|
|
|
if (type->code () != TYPE_CODE_ARRAY)
|
|
|
|
|
error (_("ALLOCATED can only be applied to arrays"));
|
|
|
|
|
struct type *result_type
|
|
|
|
|
= builtin_f_type (exp->gdbarch)->builtin_logical;
|
|
|
|
|
LONGEST result_value = type_not_allocated (type) ? 0 : 1;
|
|
|
|
|
return value_from_longest (result_type, result_value);
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-16 16:16:59 +00:00
|
|
|
|
/* Special expression evaluation cases for Fortran. */
|
2019-11-26 12:12:01 -05:00
|
|
|
|
|
|
|
|
|
static struct value *
|
2019-01-16 16:16:59 +00:00
|
|
|
|
evaluate_subexp_f (struct type *expect_type, struct expression *exp,
|
|
|
|
|
int *pos, enum noside noside)
|
|
|
|
|
{
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
struct value *arg1 = NULL, *arg2 = NULL;
|
2019-01-16 16:42:10 +00:00
|
|
|
|
enum exp_opcode op;
|
|
|
|
|
int pc;
|
|
|
|
|
struct type *type;
|
|
|
|
|
|
|
|
|
|
pc = *pos;
|
|
|
|
|
*pos += 1;
|
|
|
|
|
op = exp->elts[pc].opcode;
|
|
|
|
|
|
|
|
|
|
switch (op)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
*pos -= 1;
|
|
|
|
|
return evaluate_subexp_standard (expect_type, exp, pos, noside);
|
|
|
|
|
|
2019-01-18 14:44:48 +00:00
|
|
|
|
case UNOP_ABS:
|
2020-08-31 10:44:33 -04:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_abs (expect_type, exp, noside, op, arg1);
|
2019-01-18 14:44:48 +00:00
|
|
|
|
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_MOD:
|
2020-08-31 10:44:33 -04:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
arg2 = evaluate_subexp (value_type (arg1), exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_mod (expect_type, exp, noside, op, arg1, arg2);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_CEILING:
|
2021-03-08 07:27:57 -07:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_ceil (expect_type, exp, noside, op, arg1);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_FLOOR:
|
2021-03-08 07:27:57 -07:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_floor (expect_type, exp, noside, op, arg1);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
2021-02-11 13:34:06 +00:00
|
|
|
|
case UNOP_FORTRAN_ALLOCATED:
|
|
|
|
|
{
|
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_allocated (expect_type, exp, noside, op, arg1);
|
2021-02-11 13:34:06 +00:00
|
|
|
|
}
|
|
|
|
|
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_FORTRAN_MODULO:
|
2021-03-08 07:27:57 -07:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
arg2 = evaluate_subexp (value_type (arg1), exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_modulo (expect_type, exp, noside, op, arg1, arg2);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_LBOUND:
|
|
|
|
|
case FORTRAN_UBOUND:
|
|
|
|
|
{
|
|
|
|
|
int nargs = longest_to_int (exp->elts[pc + 1].longconst);
|
|
|
|
|
(*pos) += 2;
|
|
|
|
|
|
|
|
|
|
/* This assertion should be enforced by the expression parser. */
|
|
|
|
|
gdb_assert (nargs == 1 || nargs == 2);
|
|
|
|
|
|
|
|
|
|
bool lbound_p = op == FORTRAN_LBOUND;
|
|
|
|
|
|
|
|
|
|
/* Check that the first argument is array like. */
|
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
fortran_require_array (value_type (arg1), lbound_p);
|
2021-02-09 15:46:13 +00:00
|
|
|
|
|
|
|
|
|
if (nargs == 1)
|
|
|
|
|
return fortran_bounds_all_dims (lbound_p, exp->gdbarch, arg1);
|
|
|
|
|
|
|
|
|
|
/* User asked for the bounds of a specific dimension of the array. */
|
|
|
|
|
arg2 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
type = check_typedef (value_type (arg2));
|
|
|
|
|
if (type->code () != TYPE_CODE_INT)
|
|
|
|
|
{
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
error (_("LBOUND second argument should be an integer"));
|
|
|
|
|
else
|
|
|
|
|
error (_("UBOUND second argument should be an integer"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return fortran_bounds_for_dimension (lbound_p, exp->gdbarch, arg1,
|
|
|
|
|
arg2);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
case FORTRAN_ASSOCIATED:
|
|
|
|
|
{
|
|
|
|
|
int nargs = longest_to_int (exp->elts[pc + 1].longconst);
|
|
|
|
|
(*pos) += 2;
|
|
|
|
|
|
|
|
|
|
/* This assertion should be enforced by the expression parser. */
|
|
|
|
|
gdb_assert (nargs == 1 || nargs == 2);
|
|
|
|
|
|
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
|
|
|
|
|
if (nargs == 1)
|
|
|
|
|
{
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
return fortran_associated (exp->gdbarch, exp->language_defn,
|
|
|
|
|
arg1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
arg2 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
|
|
|
|
return fortran_associated (exp->gdbarch, exp->language_defn,
|
|
|
|
|
arg1, arg2);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_FORTRAN_CMPLX:
|
2020-08-31 10:44:33 -04:00
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
arg2 = evaluate_subexp (value_type (arg1), exp, pos, noside);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_cmplx (expect_type, exp, noside, op, arg1, arg2);
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
case UNOP_FORTRAN_KIND:
|
2019-01-16 16:42:10 +00:00
|
|
|
|
arg1 = evaluate_subexp (NULL, exp, pos, EVAL_AVOID_SIDE_EFFECTS);
|
2021-03-08 07:27:57 -07:00
|
|
|
|
return eval_op_f_kind (expect_type, exp, noside, op, arg1);
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
|
|
|
|
case OP_F77_UNDETERMINED_ARGLIST:
|
|
|
|
|
/* Remember that in F77, functions, substring ops and array subscript
|
gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c). I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it? What if the lines around it are also
wrong, do I fix them too? I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.
So I propose to fix as much as possible once and for all (hopefully).
One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines. My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for. So you
already need a somewhat efficient way to do this.
Using some interactive tool, rather than plain git-blame, makes this
trivial. For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too. My point is that it won't
really make archeology more difficult.
The other typical counter argument is that it will cause conflicts with
existing patches. That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve. I have also tried "git
rebase --ignore-whitespace", it seems to work well. Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).
gdb/ChangeLog:
* aarch64-linux-tdep.c: Fix indentation.
* aarch64-ravenscar-thread.c: Fix indentation.
* aarch64-tdep.c: Fix indentation.
* aarch64-tdep.h: Fix indentation.
* ada-lang.c: Fix indentation.
* ada-lang.h: Fix indentation.
* ada-tasks.c: Fix indentation.
* ada-typeprint.c: Fix indentation.
* ada-valprint.c: Fix indentation.
* ada-varobj.c: Fix indentation.
* addrmap.c: Fix indentation.
* addrmap.h: Fix indentation.
* agent.c: Fix indentation.
* aix-thread.c: Fix indentation.
* alpha-bsd-nat.c: Fix indentation.
* alpha-linux-tdep.c: Fix indentation.
* alpha-mdebug-tdep.c: Fix indentation.
* alpha-nbsd-tdep.c: Fix indentation.
* alpha-obsd-tdep.c: Fix indentation.
* alpha-tdep.c: Fix indentation.
* amd64-bsd-nat.c: Fix indentation.
* amd64-darwin-tdep.c: Fix indentation.
* amd64-linux-nat.c: Fix indentation.
* amd64-linux-tdep.c: Fix indentation.
* amd64-nat.c: Fix indentation.
* amd64-obsd-tdep.c: Fix indentation.
* amd64-tdep.c: Fix indentation.
* amd64-windows-tdep.c: Fix indentation.
* annotate.c: Fix indentation.
* arc-tdep.c: Fix indentation.
* arch-utils.c: Fix indentation.
* arch/arm-get-next-pcs.c: Fix indentation.
* arch/arm.c: Fix indentation.
* arm-linux-nat.c: Fix indentation.
* arm-linux-tdep.c: Fix indentation.
* arm-nbsd-tdep.c: Fix indentation.
* arm-pikeos-tdep.c: Fix indentation.
* arm-tdep.c: Fix indentation.
* arm-tdep.h: Fix indentation.
* arm-wince-tdep.c: Fix indentation.
* auto-load.c: Fix indentation.
* auxv.c: Fix indentation.
* avr-tdep.c: Fix indentation.
* ax-gdb.c: Fix indentation.
* ax-general.c: Fix indentation.
* bfin-linux-tdep.c: Fix indentation.
* block.c: Fix indentation.
* block.h: Fix indentation.
* blockframe.c: Fix indentation.
* bpf-tdep.c: Fix indentation.
* break-catch-sig.c: Fix indentation.
* break-catch-syscall.c: Fix indentation.
* break-catch-throw.c: Fix indentation.
* breakpoint.c: Fix indentation.
* breakpoint.h: Fix indentation.
* bsd-uthread.c: Fix indentation.
* btrace.c: Fix indentation.
* build-id.c: Fix indentation.
* buildsym-legacy.h: Fix indentation.
* buildsym.c: Fix indentation.
* c-typeprint.c: Fix indentation.
* c-valprint.c: Fix indentation.
* c-varobj.c: Fix indentation.
* charset.c: Fix indentation.
* cli/cli-cmds.c: Fix indentation.
* cli/cli-decode.c: Fix indentation.
* cli/cli-decode.h: Fix indentation.
* cli/cli-script.c: Fix indentation.
* cli/cli-setshow.c: Fix indentation.
* coff-pe-read.c: Fix indentation.
* coffread.c: Fix indentation.
* compile/compile-cplus-types.c: Fix indentation.
* compile/compile-object-load.c: Fix indentation.
* compile/compile-object-run.c: Fix indentation.
* completer.c: Fix indentation.
* corefile.c: Fix indentation.
* corelow.c: Fix indentation.
* cp-abi.h: Fix indentation.
* cp-namespace.c: Fix indentation.
* cp-support.c: Fix indentation.
* cp-valprint.c: Fix indentation.
* cris-linux-tdep.c: Fix indentation.
* cris-tdep.c: Fix indentation.
* darwin-nat-info.c: Fix indentation.
* darwin-nat.c: Fix indentation.
* darwin-nat.h: Fix indentation.
* dbxread.c: Fix indentation.
* dcache.c: Fix indentation.
* disasm.c: Fix indentation.
* dtrace-probe.c: Fix indentation.
* dwarf2/abbrev.c: Fix indentation.
* dwarf2/attribute.c: Fix indentation.
* dwarf2/expr.c: Fix indentation.
* dwarf2/frame.c: Fix indentation.
* dwarf2/index-cache.c: Fix indentation.
* dwarf2/index-write.c: Fix indentation.
* dwarf2/line-header.c: Fix indentation.
* dwarf2/loc.c: Fix indentation.
* dwarf2/macro.c: Fix indentation.
* dwarf2/read.c: Fix indentation.
* dwarf2/read.h: Fix indentation.
* elfread.c: Fix indentation.
* eval.c: Fix indentation.
* event-top.c: Fix indentation.
* exec.c: Fix indentation.
* exec.h: Fix indentation.
* expprint.c: Fix indentation.
* f-lang.c: Fix indentation.
* f-typeprint.c: Fix indentation.
* f-valprint.c: Fix indentation.
* fbsd-nat.c: Fix indentation.
* fbsd-tdep.c: Fix indentation.
* findvar.c: Fix indentation.
* fork-child.c: Fix indentation.
* frame-unwind.c: Fix indentation.
* frame-unwind.h: Fix indentation.
* frame.c: Fix indentation.
* frv-linux-tdep.c: Fix indentation.
* frv-tdep.c: Fix indentation.
* frv-tdep.h: Fix indentation.
* ft32-tdep.c: Fix indentation.
* gcore.c: Fix indentation.
* gdb_bfd.c: Fix indentation.
* gdbarch.sh: Fix indentation.
* gdbarch.c: Re-generate
* gdbarch.h: Re-generate.
* gdbcore.h: Fix indentation.
* gdbthread.h: Fix indentation.
* gdbtypes.c: Fix indentation.
* gdbtypes.h: Fix indentation.
* glibc-tdep.c: Fix indentation.
* gnu-nat.c: Fix indentation.
* gnu-nat.h: Fix indentation.
* gnu-v2-abi.c: Fix indentation.
* gnu-v3-abi.c: Fix indentation.
* go32-nat.c: Fix indentation.
* guile/guile-internal.h: Fix indentation.
* guile/scm-cmd.c: Fix indentation.
* guile/scm-frame.c: Fix indentation.
* guile/scm-iterator.c: Fix indentation.
* guile/scm-math.c: Fix indentation.
* guile/scm-ports.c: Fix indentation.
* guile/scm-pretty-print.c: Fix indentation.
* guile/scm-value.c: Fix indentation.
* h8300-tdep.c: Fix indentation.
* hppa-linux-nat.c: Fix indentation.
* hppa-linux-tdep.c: Fix indentation.
* hppa-nbsd-nat.c: Fix indentation.
* hppa-nbsd-tdep.c: Fix indentation.
* hppa-obsd-nat.c: Fix indentation.
* hppa-tdep.c: Fix indentation.
* hppa-tdep.h: Fix indentation.
* i386-bsd-nat.c: Fix indentation.
* i386-darwin-nat.c: Fix indentation.
* i386-darwin-tdep.c: Fix indentation.
* i386-dicos-tdep.c: Fix indentation.
* i386-gnu-nat.c: Fix indentation.
* i386-linux-nat.c: Fix indentation.
* i386-linux-tdep.c: Fix indentation.
* i386-nto-tdep.c: Fix indentation.
* i386-obsd-tdep.c: Fix indentation.
* i386-sol2-nat.c: Fix indentation.
* i386-tdep.c: Fix indentation.
* i386-tdep.h: Fix indentation.
* i386-windows-tdep.c: Fix indentation.
* i387-tdep.c: Fix indentation.
* i387-tdep.h: Fix indentation.
* ia64-libunwind-tdep.c: Fix indentation.
* ia64-libunwind-tdep.h: Fix indentation.
* ia64-linux-nat.c: Fix indentation.
* ia64-linux-tdep.c: Fix indentation.
* ia64-tdep.c: Fix indentation.
* ia64-tdep.h: Fix indentation.
* ia64-vms-tdep.c: Fix indentation.
* infcall.c: Fix indentation.
* infcmd.c: Fix indentation.
* inferior.c: Fix indentation.
* infrun.c: Fix indentation.
* iq2000-tdep.c: Fix indentation.
* language.c: Fix indentation.
* linespec.c: Fix indentation.
* linux-fork.c: Fix indentation.
* linux-nat.c: Fix indentation.
* linux-tdep.c: Fix indentation.
* linux-thread-db.c: Fix indentation.
* lm32-tdep.c: Fix indentation.
* m2-lang.c: Fix indentation.
* m2-typeprint.c: Fix indentation.
* m2-valprint.c: Fix indentation.
* m32c-tdep.c: Fix indentation.
* m32r-linux-tdep.c: Fix indentation.
* m32r-tdep.c: Fix indentation.
* m68hc11-tdep.c: Fix indentation.
* m68k-bsd-nat.c: Fix indentation.
* m68k-linux-nat.c: Fix indentation.
* m68k-linux-tdep.c: Fix indentation.
* m68k-tdep.c: Fix indentation.
* machoread.c: Fix indentation.
* macrocmd.c: Fix indentation.
* macroexp.c: Fix indentation.
* macroscope.c: Fix indentation.
* macrotab.c: Fix indentation.
* macrotab.h: Fix indentation.
* main.c: Fix indentation.
* mdebugread.c: Fix indentation.
* mep-tdep.c: Fix indentation.
* mi/mi-cmd-catch.c: Fix indentation.
* mi/mi-cmd-disas.c: Fix indentation.
* mi/mi-cmd-env.c: Fix indentation.
* mi/mi-cmd-stack.c: Fix indentation.
* mi/mi-cmd-var.c: Fix indentation.
* mi/mi-cmds.c: Fix indentation.
* mi/mi-main.c: Fix indentation.
* mi/mi-parse.c: Fix indentation.
* microblaze-tdep.c: Fix indentation.
* minidebug.c: Fix indentation.
* minsyms.c: Fix indentation.
* mips-linux-nat.c: Fix indentation.
* mips-linux-tdep.c: Fix indentation.
* mips-nbsd-tdep.c: Fix indentation.
* mips-tdep.c: Fix indentation.
* mn10300-linux-tdep.c: Fix indentation.
* mn10300-tdep.c: Fix indentation.
* moxie-tdep.c: Fix indentation.
* msp430-tdep.c: Fix indentation.
* namespace.h: Fix indentation.
* nat/fork-inferior.c: Fix indentation.
* nat/gdb_ptrace.h: Fix indentation.
* nat/linux-namespaces.c: Fix indentation.
* nat/linux-osdata.c: Fix indentation.
* nat/netbsd-nat.c: Fix indentation.
* nat/x86-dregs.c: Fix indentation.
* nbsd-nat.c: Fix indentation.
* nbsd-tdep.c: Fix indentation.
* nios2-linux-tdep.c: Fix indentation.
* nios2-tdep.c: Fix indentation.
* nto-procfs.c: Fix indentation.
* nto-tdep.c: Fix indentation.
* objfiles.c: Fix indentation.
* objfiles.h: Fix indentation.
* opencl-lang.c: Fix indentation.
* or1k-tdep.c: Fix indentation.
* osabi.c: Fix indentation.
* osabi.h: Fix indentation.
* osdata.c: Fix indentation.
* p-lang.c: Fix indentation.
* p-typeprint.c: Fix indentation.
* p-valprint.c: Fix indentation.
* parse.c: Fix indentation.
* ppc-linux-nat.c: Fix indentation.
* ppc-linux-tdep.c: Fix indentation.
* ppc-nbsd-nat.c: Fix indentation.
* ppc-nbsd-tdep.c: Fix indentation.
* ppc-obsd-nat.c: Fix indentation.
* ppc-ravenscar-thread.c: Fix indentation.
* ppc-sysv-tdep.c: Fix indentation.
* ppc64-tdep.c: Fix indentation.
* printcmd.c: Fix indentation.
* proc-api.c: Fix indentation.
* producer.c: Fix indentation.
* producer.h: Fix indentation.
* prologue-value.c: Fix indentation.
* prologue-value.h: Fix indentation.
* psymtab.c: Fix indentation.
* python/py-arch.c: Fix indentation.
* python/py-bpevent.c: Fix indentation.
* python/py-event.c: Fix indentation.
* python/py-event.h: Fix indentation.
* python/py-finishbreakpoint.c: Fix indentation.
* python/py-frame.c: Fix indentation.
* python/py-framefilter.c: Fix indentation.
* python/py-inferior.c: Fix indentation.
* python/py-infthread.c: Fix indentation.
* python/py-objfile.c: Fix indentation.
* python/py-prettyprint.c: Fix indentation.
* python/py-registers.c: Fix indentation.
* python/py-signalevent.c: Fix indentation.
* python/py-stopevent.c: Fix indentation.
* python/py-stopevent.h: Fix indentation.
* python/py-threadevent.c: Fix indentation.
* python/py-tui.c: Fix indentation.
* python/py-unwind.c: Fix indentation.
* python/py-value.c: Fix indentation.
* python/py-xmethods.c: Fix indentation.
* python/python-internal.h: Fix indentation.
* python/python.c: Fix indentation.
* ravenscar-thread.c: Fix indentation.
* record-btrace.c: Fix indentation.
* record-full.c: Fix indentation.
* record.c: Fix indentation.
* reggroups.c: Fix indentation.
* regset.h: Fix indentation.
* remote-fileio.c: Fix indentation.
* remote.c: Fix indentation.
* reverse.c: Fix indentation.
* riscv-linux-tdep.c: Fix indentation.
* riscv-ravenscar-thread.c: Fix indentation.
* riscv-tdep.c: Fix indentation.
* rl78-tdep.c: Fix indentation.
* rs6000-aix-tdep.c: Fix indentation.
* rs6000-lynx178-tdep.c: Fix indentation.
* rs6000-nat.c: Fix indentation.
* rs6000-tdep.c: Fix indentation.
* rust-lang.c: Fix indentation.
* rx-tdep.c: Fix indentation.
* s12z-tdep.c: Fix indentation.
* s390-linux-tdep.c: Fix indentation.
* score-tdep.c: Fix indentation.
* ser-base.c: Fix indentation.
* ser-mingw.c: Fix indentation.
* ser-uds.c: Fix indentation.
* ser-unix.c: Fix indentation.
* serial.c: Fix indentation.
* sh-linux-tdep.c: Fix indentation.
* sh-nbsd-tdep.c: Fix indentation.
* sh-tdep.c: Fix indentation.
* skip.c: Fix indentation.
* sol-thread.c: Fix indentation.
* solib-aix.c: Fix indentation.
* solib-darwin.c: Fix indentation.
* solib-frv.c: Fix indentation.
* solib-svr4.c: Fix indentation.
* solib.c: Fix indentation.
* source.c: Fix indentation.
* sparc-linux-tdep.c: Fix indentation.
* sparc-nbsd-tdep.c: Fix indentation.
* sparc-obsd-tdep.c: Fix indentation.
* sparc-ravenscar-thread.c: Fix indentation.
* sparc-tdep.c: Fix indentation.
* sparc64-linux-tdep.c: Fix indentation.
* sparc64-nbsd-tdep.c: Fix indentation.
* sparc64-obsd-tdep.c: Fix indentation.
* sparc64-tdep.c: Fix indentation.
* stabsread.c: Fix indentation.
* stack.c: Fix indentation.
* stap-probe.c: Fix indentation.
* stubs/ia64vms-stub.c: Fix indentation.
* stubs/m32r-stub.c: Fix indentation.
* stubs/m68k-stub.c: Fix indentation.
* stubs/sh-stub.c: Fix indentation.
* stubs/sparc-stub.c: Fix indentation.
* symfile-mem.c: Fix indentation.
* symfile.c: Fix indentation.
* symfile.h: Fix indentation.
* symmisc.c: Fix indentation.
* symtab.c: Fix indentation.
* symtab.h: Fix indentation.
* target-float.c: Fix indentation.
* target.c: Fix indentation.
* target.h: Fix indentation.
* tic6x-tdep.c: Fix indentation.
* tilegx-linux-tdep.c: Fix indentation.
* tilegx-tdep.c: Fix indentation.
* top.c: Fix indentation.
* tracefile-tfile.c: Fix indentation.
* tracepoint.c: Fix indentation.
* tui/tui-disasm.c: Fix indentation.
* tui/tui-io.c: Fix indentation.
* tui/tui-regs.c: Fix indentation.
* tui/tui-stack.c: Fix indentation.
* tui/tui-win.c: Fix indentation.
* tui/tui-winsource.c: Fix indentation.
* tui/tui.c: Fix indentation.
* typeprint.c: Fix indentation.
* ui-out.h: Fix indentation.
* unittests/copy_bitwise-selftests.c: Fix indentation.
* unittests/memory-map-selftests.c: Fix indentation.
* utils.c: Fix indentation.
* v850-tdep.c: Fix indentation.
* valarith.c: Fix indentation.
* valops.c: Fix indentation.
* valprint.c: Fix indentation.
* valprint.h: Fix indentation.
* value.c: Fix indentation.
* value.h: Fix indentation.
* varobj.c: Fix indentation.
* vax-tdep.c: Fix indentation.
* windows-nat.c: Fix indentation.
* windows-tdep.c: Fix indentation.
* xcoffread.c: Fix indentation.
* xml-syscall.c: Fix indentation.
* xml-tdesc.c: Fix indentation.
* xstormy16-tdep.c: Fix indentation.
* xtensa-config.c: Fix indentation.
* xtensa-linux-nat.c: Fix indentation.
* xtensa-linux-tdep.c: Fix indentation.
* xtensa-tdep.c: Fix indentation.
gdbserver/ChangeLog:
* ax.cc: Fix indentation.
* dll.cc: Fix indentation.
* inferiors.h: Fix indentation.
* linux-low.cc: Fix indentation.
* linux-nios2-low.cc: Fix indentation.
* linux-ppc-ipa.cc: Fix indentation.
* linux-ppc-low.cc: Fix indentation.
* linux-x86-low.cc: Fix indentation.
* linux-xtensa-low.cc: Fix indentation.
* regcache.cc: Fix indentation.
* server.cc: Fix indentation.
* tracepoint.cc: Fix indentation.
gdbsupport/ChangeLog:
* common-exceptions.h: Fix indentation.
* event-loop.cc: Fix indentation.
* fileio.cc: Fix indentation.
* filestuff.cc: Fix indentation.
* gdb-dlfcn.cc: Fix indentation.
* gdb_string_view.h: Fix indentation.
* job-control.cc: Fix indentation.
* signals.cc: Fix indentation.
Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-11-02 10:26:14 -05:00
|
|
|
|
operations cannot be disambiguated at parse time. We have made
|
|
|
|
|
all array subscript operations, substring operations as well as
|
|
|
|
|
function calls come here and we now have to discover what the heck
|
|
|
|
|
this thing actually was. If it is a function, we process just as
|
|
|
|
|
if we got an OP_FUNCALL. */
|
2020-05-07 16:27:16 +01:00
|
|
|
|
int nargs = longest_to_int (exp->elts[pc + 1].longconst);
|
|
|
|
|
(*pos) += 2;
|
|
|
|
|
|
|
|
|
|
/* First determine the type code we are dealing with. */
|
|
|
|
|
arg1 = evaluate_subexp (nullptr, exp, pos, noside);
|
|
|
|
|
type = check_typedef (value_type (arg1));
|
|
|
|
|
enum type_code code = type->code ();
|
|
|
|
|
|
|
|
|
|
if (code == TYPE_CODE_PTR)
|
|
|
|
|
{
|
|
|
|
|
/* Fortran always passes variable to subroutines as pointer.
|
|
|
|
|
So we need to look into its target type to see if it is
|
|
|
|
|
array, string or function. If it is, we need to switch
|
|
|
|
|
to the target value the original one points to. */
|
|
|
|
|
struct type *target_type = check_typedef (TYPE_TARGET_TYPE (type));
|
|
|
|
|
|
|
|
|
|
if (target_type->code () == TYPE_CODE_ARRAY
|
|
|
|
|
|| target_type->code () == TYPE_CODE_STRING
|
|
|
|
|
|| target_type->code () == TYPE_CODE_FUNC)
|
|
|
|
|
{
|
|
|
|
|
arg1 = value_ind (arg1);
|
|
|
|
|
type = check_typedef (value_type (arg1));
|
|
|
|
|
code = type->code ();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_ARRAY:
|
|
|
|
|
case TYPE_CODE_STRING:
|
|
|
|
|
return fortran_value_subarray (arg1, exp, pos, nargs, noside);
|
|
|
|
|
|
|
|
|
|
case TYPE_CODE_PTR:
|
|
|
|
|
case TYPE_CODE_FUNC:
|
|
|
|
|
case TYPE_CODE_INTERNAL_FUNCTION:
|
|
|
|
|
{
|
|
|
|
|
/* It's a function call. Allocate arg vector, including
|
|
|
|
|
space for the function to be called in argvec[0] and a
|
|
|
|
|
termination NULL. */
|
|
|
|
|
struct value **argvec = (struct value **)
|
|
|
|
|
alloca (sizeof (struct value *) * (nargs + 2));
|
|
|
|
|
argvec[0] = arg1;
|
|
|
|
|
int tem = 1;
|
|
|
|
|
for (; tem <= nargs; tem++)
|
|
|
|
|
{
|
gdb/fortran: don't access non-existent type fields
When attempting to call a Fortran function for which there is no debug
information we currently trigger undefined behaviour in GDB by
accessing non-existent type fields.
The reason is that in order to prepare the arguments, for a call to a
Fortran function, we need to know the type of each argument. If the
function being called has no debug information then obviously GDB
doesn't know about the argument types and we should either give the
user an error or pick a suitable default. What we currently do is
just assume the field exist and access undefined memory, which is
clearly wrong.
The reason GDB needs to know the argument type is to tell if the
argument is artificial or not, artificial arguments will be passed by
value while non-artificial arguments will be passed by reference.
An ideal solution for this problem would be to allow the user to cast
the function to the correct type, we already do this to some degree
with the return value, for example:
(gdb) print some_func_ ()
'some_func_' has unknown return type; cast the call to its declared return type
(gdb) print (integer) some_func_ ()
$1 = 1
But if we could extend this to allow casting to the full function
type, GDB could figure out from the signature what are real
parameters, and what are artificial parameters. Maybe something like
this:
(gdb) print ((integer () (integer, double)) some_other_func_ (1, 2.3)
Alas, right now the Fortran expression parser doesn't seem to support
parsing function signatures, and we certainly don't have support for
figuring out real vs artificial arguments from a signature.
Still, I think we can prevent GDB from accessing undefined memory and
provide a reasonable default behaviour.
In this commit I:
- Only ask if the argument is artificial if the type of the argument
is actually known.
- Unknown arguments are assumed to be artificial and passed by
value (non-artificial arguments are pass by reference).
- If an artificial argument is prefixed with '&' by the user then we
treat the argument as pass-by-reference.
With these three changes we avoid undefined behaviour in GDB, and
allow the user, in most cases, to get a reasonably natural default
behaviour.
gdb/ChangeLog:
PR fortran/26155
* f-lang.c (fortran_argument_convert): Delete declaration.
(fortran_prepare_argument): New function.
(evaluate_subexp_f): Move logic to new function
fortran_prepare_argument.
gdb/testsuite/ChangeLog:
PR fortran/26155
* gdb.fortran/call-no-debug-func.f90: New file.
* gdb.fortran/call-no-debug-prog.f90: New file.
* gdb.fortran/call-no-debug.exp: New file.
2020-11-13 10:39:23 +00:00
|
|
|
|
bool is_internal_func = (code == TYPE_CODE_INTERNAL_FUNCTION);
|
|
|
|
|
argvec[tem]
|
|
|
|
|
= fortran_prepare_argument (exp, pos, (tem - 1),
|
|
|
|
|
is_internal_func,
|
|
|
|
|
value_type (arg1), noside);
|
2020-05-07 16:27:16 +01:00
|
|
|
|
}
|
|
|
|
|
argvec[tem] = 0; /* signal end of arglist */
|
|
|
|
|
if (noside == EVAL_SKIP)
|
|
|
|
|
return eval_skip_value (exp);
|
2020-12-15 17:53:34 -07:00
|
|
|
|
return evaluate_subexp_do_call (exp, noside, argvec[0],
|
|
|
|
|
gdb::make_array_view (argvec + 1,
|
|
|
|
|
nargs),
|
|
|
|
|
NULL, expect_type);
|
2020-05-07 16:27:16 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
error (_("Cannot perform substring on this type"));
|
|
|
|
|
}
|
2019-01-16 16:42:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Should be unreachable. */
|
|
|
|
|
return nullptr;
|
2019-01-16 16:16:59 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
namespace expr
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
/* Called from evaluate to perform array indexing, and sub-range
|
|
|
|
|
extraction, for Fortran. As well as arrays this function also
|
|
|
|
|
handles strings as they can be treated like arrays of characters.
|
|
|
|
|
ARRAY is the array or string being accessed. EXP and NOSIDE are as
|
|
|
|
|
for evaluate. */
|
|
|
|
|
|
|
|
|
|
value *
|
|
|
|
|
fortran_undetermined::value_subarray (value *array,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
type *original_array_type = check_typedef (value_type (array));
|
|
|
|
|
bool is_string_p = original_array_type->code () == TYPE_CODE_STRING;
|
|
|
|
|
const std::vector<operation_up> &ops = std::get<1> (m_storage);
|
|
|
|
|
int nargs = ops.size ();
|
|
|
|
|
|
|
|
|
|
/* Perform checks for ARRAY not being available. The somewhat overly
|
|
|
|
|
complex logic here is just to keep backward compatibility with the
|
|
|
|
|
errors that we used to get before FORTRAN_VALUE_SUBARRAY was
|
|
|
|
|
rewritten. Maybe a future task would streamline the error messages we
|
|
|
|
|
get here, and update all the expected test results. */
|
|
|
|
|
if (ops[0]->opcode () != OP_RANGE)
|
|
|
|
|
{
|
|
|
|
|
if (type_not_associated (original_array_type))
|
|
|
|
|
error (_("no such vector element (vector not associated)"));
|
|
|
|
|
else if (type_not_allocated (original_array_type))
|
|
|
|
|
error (_("no such vector element (vector not allocated)"));
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (type_not_associated (original_array_type))
|
|
|
|
|
error (_("array not associated"));
|
|
|
|
|
else if (type_not_allocated (original_array_type))
|
|
|
|
|
error (_("array not allocated"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* First check that the number of dimensions in the type we are slicing
|
|
|
|
|
matches the number of arguments we were passed. */
|
|
|
|
|
int ndimensions = calc_f77_array_dims (original_array_type);
|
|
|
|
|
if (nargs != ndimensions)
|
|
|
|
|
error (_("Wrong number of subscripts"));
|
|
|
|
|
|
|
|
|
|
/* This will be initialised below with the type of the elements held in
|
|
|
|
|
ARRAY. */
|
|
|
|
|
struct type *inner_element_type;
|
|
|
|
|
|
|
|
|
|
/* Extract the types of each array dimension from the original array
|
|
|
|
|
type. We need these available so we can fill in the default upper and
|
|
|
|
|
lower bounds if the user requested slice doesn't provide that
|
|
|
|
|
information. Additionally unpacking the dimensions like this gives us
|
|
|
|
|
the inner element type. */
|
|
|
|
|
std::vector<struct type *> dim_types;
|
|
|
|
|
{
|
|
|
|
|
dim_types.reserve (ndimensions);
|
|
|
|
|
struct type *type = original_array_type;
|
|
|
|
|
for (int i = 0; i < ndimensions; ++i)
|
|
|
|
|
{
|
|
|
|
|
dim_types.push_back (type);
|
|
|
|
|
type = TYPE_TARGET_TYPE (type);
|
|
|
|
|
}
|
|
|
|
|
/* TYPE is now the inner element type of the array, we start the new
|
|
|
|
|
array slice off as this type, then as we process the requested slice
|
|
|
|
|
(from the user) we wrap new types around this to build up the final
|
|
|
|
|
slice type. */
|
|
|
|
|
inner_element_type = type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* As we analyse the new slice type we need to understand if the data
|
|
|
|
|
being referenced is contiguous. Do decide this we must track the size
|
|
|
|
|
of an element at each dimension of the new slice array. Initially the
|
|
|
|
|
elements of the inner most dimension of the array are the same inner
|
|
|
|
|
most elements as the original ARRAY. */
|
|
|
|
|
LONGEST slice_element_size = TYPE_LENGTH (inner_element_type);
|
|
|
|
|
|
|
|
|
|
/* Start off assuming all data is contiguous, this will be set to false
|
|
|
|
|
if access to any dimension results in non-contiguous data. */
|
|
|
|
|
bool is_all_contiguous = true;
|
|
|
|
|
|
|
|
|
|
/* The TOTAL_OFFSET is the distance in bytes from the start of the
|
|
|
|
|
original ARRAY to the start of the new slice. This is calculated as
|
|
|
|
|
we process the information from the user. */
|
|
|
|
|
LONGEST total_offset = 0;
|
|
|
|
|
|
|
|
|
|
/* A structure representing information about each dimension of the
|
|
|
|
|
resulting slice. */
|
|
|
|
|
struct slice_dim
|
|
|
|
|
{
|
|
|
|
|
/* Constructor. */
|
|
|
|
|
slice_dim (LONGEST l, LONGEST h, LONGEST s, struct type *idx)
|
|
|
|
|
: low (l),
|
|
|
|
|
high (h),
|
|
|
|
|
stride (s),
|
|
|
|
|
index (idx)
|
|
|
|
|
{ /* Nothing. */ }
|
|
|
|
|
|
|
|
|
|
/* The low bound for this dimension of the slice. */
|
|
|
|
|
LONGEST low;
|
|
|
|
|
|
|
|
|
|
/* The high bound for this dimension of the slice. */
|
|
|
|
|
LONGEST high;
|
|
|
|
|
|
|
|
|
|
/* The byte stride for this dimension of the slice. */
|
|
|
|
|
LONGEST stride;
|
|
|
|
|
|
|
|
|
|
struct type *index;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* The dimensions of the resulting slice. */
|
|
|
|
|
std::vector<slice_dim> slice_dims;
|
|
|
|
|
|
|
|
|
|
/* Process the incoming arguments. These arguments are in the reverse
|
|
|
|
|
order to the array dimensions, that is the first argument refers to
|
|
|
|
|
the last array dimension. */
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
debug_printf ("Processing array access:\n");
|
|
|
|
|
for (int i = 0; i < nargs; ++i)
|
|
|
|
|
{
|
|
|
|
|
/* For each dimension of the array the user will have either provided
|
|
|
|
|
a ranged access with optional lower bound, upper bound, and
|
|
|
|
|
stride, or the user will have supplied a single index. */
|
|
|
|
|
struct type *dim_type = dim_types[ndimensions - (i + 1)];
|
|
|
|
|
fortran_range_operation *range_op
|
|
|
|
|
= dynamic_cast<fortran_range_operation *> (ops[i].get ());
|
|
|
|
|
if (range_op != nullptr)
|
|
|
|
|
{
|
|
|
|
|
enum range_flag range_flag = range_op->get_flags ();
|
|
|
|
|
|
|
|
|
|
LONGEST low, high, stride;
|
|
|
|
|
low = high = stride = 0;
|
|
|
|
|
|
|
|
|
|
if ((range_flag & RANGE_LOW_BOUND_DEFAULT) == 0)
|
|
|
|
|
low = value_as_long (range_op->evaluate0 (exp, noside));
|
|
|
|
|
else
|
|
|
|
|
low = f77_get_lowerbound (dim_type);
|
|
|
|
|
if ((range_flag & RANGE_HIGH_BOUND_DEFAULT) == 0)
|
|
|
|
|
high = value_as_long (range_op->evaluate1 (exp, noside));
|
|
|
|
|
else
|
|
|
|
|
high = f77_get_upperbound (dim_type);
|
|
|
|
|
if ((range_flag & RANGE_HAS_STRIDE) == RANGE_HAS_STRIDE)
|
|
|
|
|
stride = value_as_long (range_op->evaluate2 (exp, noside));
|
|
|
|
|
else
|
|
|
|
|
stride = 1;
|
|
|
|
|
|
|
|
|
|
if (stride == 0)
|
|
|
|
|
error (_("stride must not be 0"));
|
|
|
|
|
|
|
|
|
|
/* Get information about this dimension in the original ARRAY. */
|
|
|
|
|
struct type *target_type = TYPE_TARGET_TYPE (dim_type);
|
|
|
|
|
struct type *index_type = dim_type->index_type ();
|
|
|
|
|
LONGEST lb = f77_get_lowerbound (dim_type);
|
|
|
|
|
LONGEST ub = f77_get_upperbound (dim_type);
|
|
|
|
|
LONGEST sd = index_type->bit_stride ();
|
|
|
|
|
if (sd == 0)
|
|
|
|
|
sd = TYPE_LENGTH (target_type) * 8;
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("|-> Range access\n");
|
|
|
|
|
std::string str = type_to_string (dim_type);
|
|
|
|
|
debug_printf ("| |-> Type: %s\n", str.c_str ());
|
|
|
|
|
debug_printf ("| |-> Array:\n");
|
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n", plongest (lb));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n", plongest (ub));
|
|
|
|
|
debug_printf ("| | |-> Bit stride: %s\n", plongest (sd));
|
|
|
|
|
debug_printf ("| | |-> Byte stride: %s\n", plongest (sd / 8));
|
|
|
|
|
debug_printf ("| | |-> Type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (dim_type)));
|
|
|
|
|
debug_printf ("| | '-> Target type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (target_type)));
|
|
|
|
|
debug_printf ("| |-> Accessing:\n");
|
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n",
|
|
|
|
|
plongest (low));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n",
|
|
|
|
|
plongest (high));
|
|
|
|
|
debug_printf ("| | '-> Element stride: %s\n",
|
|
|
|
|
plongest (stride));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check the user hasn't asked for something invalid. */
|
|
|
|
|
if (high > ub || low < lb)
|
|
|
|
|
error (_("array subscript out of bounds"));
|
|
|
|
|
|
|
|
|
|
/* Calculate what this dimension of the new slice array will look
|
|
|
|
|
like. OFFSET is the byte offset from the start of the
|
|
|
|
|
previous (more outer) dimension to the start of this
|
|
|
|
|
dimension. E_COUNT is the number of elements in this
|
|
|
|
|
dimension. REMAINDER is the number of elements remaining
|
|
|
|
|
between the last included element and the upper bound. For
|
|
|
|
|
example an access '1:6:2' will include elements 1, 3, 5 and
|
|
|
|
|
have a remainder of 1 (element #6). */
|
|
|
|
|
LONGEST lowest = std::min (low, high);
|
|
|
|
|
LONGEST offset = (sd / 8) * (lowest - lb);
|
|
|
|
|
LONGEST e_count = std::abs (high - low) + 1;
|
|
|
|
|
e_count = (e_count + (std::abs (stride) - 1)) / std::abs (stride);
|
|
|
|
|
LONGEST new_low = 1;
|
|
|
|
|
LONGEST new_high = new_low + e_count - 1;
|
|
|
|
|
LONGEST new_stride = (sd * stride) / 8;
|
|
|
|
|
LONGEST last_elem = low + ((e_count - 1) * stride);
|
|
|
|
|
LONGEST remainder = high - last_elem;
|
|
|
|
|
if (low > high)
|
|
|
|
|
{
|
|
|
|
|
offset += std::abs (remainder) * TYPE_LENGTH (target_type);
|
|
|
|
|
if (stride > 0)
|
|
|
|
|
error (_("incorrect stride and boundary combination"));
|
|
|
|
|
}
|
|
|
|
|
else if (stride < 0)
|
|
|
|
|
error (_("incorrect stride and boundary combination"));
|
|
|
|
|
|
|
|
|
|
/* Is the data within this dimension contiguous? It is if the
|
|
|
|
|
newly computed stride is the same size as a single element of
|
|
|
|
|
this dimension. */
|
|
|
|
|
bool is_dim_contiguous = (new_stride == slice_element_size);
|
|
|
|
|
is_all_contiguous &= is_dim_contiguous;
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("| '-> Results:\n");
|
|
|
|
|
debug_printf ("| |-> Offset = %s\n", plongest (offset));
|
|
|
|
|
debug_printf ("| |-> Elements = %s\n", plongest (e_count));
|
|
|
|
|
debug_printf ("| |-> Low bound = %s\n", plongest (new_low));
|
|
|
|
|
debug_printf ("| |-> High bound = %s\n",
|
|
|
|
|
plongest (new_high));
|
|
|
|
|
debug_printf ("| |-> Byte stride = %s\n",
|
|
|
|
|
plongest (new_stride));
|
|
|
|
|
debug_printf ("| |-> Last element = %s\n",
|
|
|
|
|
plongest (last_elem));
|
|
|
|
|
debug_printf ("| |-> Remainder = %s\n",
|
|
|
|
|
plongest (remainder));
|
|
|
|
|
debug_printf ("| '-> Contiguous = %s\n",
|
|
|
|
|
(is_dim_contiguous ? "Yes" : "No"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Figure out how big (in bytes) an element of this dimension of
|
|
|
|
|
the new array slice will be. */
|
|
|
|
|
slice_element_size = std::abs (new_stride * e_count);
|
|
|
|
|
|
|
|
|
|
slice_dims.emplace_back (new_low, new_high, new_stride,
|
|
|
|
|
index_type);
|
|
|
|
|
|
|
|
|
|
/* Update the total offset. */
|
|
|
|
|
total_offset += offset;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* There is a single index for this dimension. */
|
|
|
|
|
LONGEST index
|
|
|
|
|
= value_as_long (ops[i]->evaluate_with_coercion (exp, noside));
|
|
|
|
|
|
|
|
|
|
/* Get information about this dimension in the original ARRAY. */
|
|
|
|
|
struct type *target_type = TYPE_TARGET_TYPE (dim_type);
|
|
|
|
|
struct type *index_type = dim_type->index_type ();
|
|
|
|
|
LONGEST lb = f77_get_lowerbound (dim_type);
|
|
|
|
|
LONGEST ub = f77_get_upperbound (dim_type);
|
|
|
|
|
LONGEST sd = index_type->bit_stride () / 8;
|
|
|
|
|
if (sd == 0)
|
|
|
|
|
sd = TYPE_LENGTH (target_type);
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("|-> Index access\n");
|
|
|
|
|
std::string str = type_to_string (dim_type);
|
|
|
|
|
debug_printf ("| |-> Type: %s\n", str.c_str ());
|
|
|
|
|
debug_printf ("| |-> Array:\n");
|
|
|
|
|
debug_printf ("| | |-> Low bound: %s\n", plongest (lb));
|
|
|
|
|
debug_printf ("| | |-> High bound: %s\n", plongest (ub));
|
|
|
|
|
debug_printf ("| | |-> Byte stride: %s\n", plongest (sd));
|
|
|
|
|
debug_printf ("| | |-> Type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (dim_type)));
|
|
|
|
|
debug_printf ("| | '-> Target type size: %s\n",
|
|
|
|
|
pulongest (TYPE_LENGTH (target_type)));
|
|
|
|
|
debug_printf ("| '-> Accessing:\n");
|
|
|
|
|
debug_printf ("| '-> Index: %s\n",
|
|
|
|
|
plongest (index));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If the array has actual content then check the index is in
|
|
|
|
|
bounds. An array without content (an unbound array) doesn't
|
|
|
|
|
have a known upper bound, so don't error check in that
|
|
|
|
|
situation. */
|
|
|
|
|
if (index < lb
|
|
|
|
|
|| (dim_type->index_type ()->bounds ()->high.kind () != PROP_UNDEFINED
|
|
|
|
|
&& index > ub)
|
|
|
|
|
|| (VALUE_LVAL (array) != lval_memory
|
|
|
|
|
&& dim_type->index_type ()->bounds ()->high.kind () == PROP_UNDEFINED))
|
|
|
|
|
{
|
|
|
|
|
if (type_not_associated (dim_type))
|
|
|
|
|
error (_("no such vector element (vector not associated)"));
|
|
|
|
|
else if (type_not_allocated (dim_type))
|
|
|
|
|
error (_("no such vector element (vector not allocated)"));
|
|
|
|
|
else
|
|
|
|
|
error (_("no such vector element"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Calculate using the type stride, not the target type size. */
|
|
|
|
|
LONGEST offset = sd * (index - lb);
|
|
|
|
|
total_offset += offset;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Build a type that represents the new array slice in the target memory
|
|
|
|
|
of the original ARRAY, this type makes use of strides to correctly
|
|
|
|
|
find only those elements that are part of the new slice. */
|
|
|
|
|
struct type *array_slice_type = inner_element_type;
|
|
|
|
|
for (const auto &d : slice_dims)
|
|
|
|
|
{
|
|
|
|
|
/* Create the range. */
|
|
|
|
|
dynamic_prop p_low, p_high, p_stride;
|
|
|
|
|
|
|
|
|
|
p_low.set_const_val (d.low);
|
|
|
|
|
p_high.set_const_val (d.high);
|
|
|
|
|
p_stride.set_const_val (d.stride);
|
|
|
|
|
|
|
|
|
|
struct type *new_range
|
|
|
|
|
= create_range_type_with_stride ((struct type *) NULL,
|
|
|
|
|
TYPE_TARGET_TYPE (d.index),
|
|
|
|
|
&p_low, &p_high, 0, &p_stride,
|
|
|
|
|
true);
|
|
|
|
|
array_slice_type
|
|
|
|
|
= create_array_type (nullptr, array_slice_type, new_range);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (fortran_array_slicing_debug)
|
|
|
|
|
{
|
|
|
|
|
debug_printf ("'-> Final result:\n");
|
|
|
|
|
debug_printf (" |-> Type: %s\n",
|
|
|
|
|
type_to_string (array_slice_type).c_str ());
|
|
|
|
|
debug_printf (" |-> Total offset: %s\n",
|
|
|
|
|
plongest (total_offset));
|
|
|
|
|
debug_printf (" |-> Base address: %s\n",
|
|
|
|
|
core_addr_to_string (value_address (array)));
|
|
|
|
|
debug_printf (" '-> Contiguous = %s\n",
|
|
|
|
|
(is_all_contiguous ? "Yes" : "No"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Should we repack this array slice? */
|
|
|
|
|
if (!is_all_contiguous && (repack_array_slices || is_string_p))
|
|
|
|
|
{
|
|
|
|
|
/* Build a type for the repacked slice. */
|
|
|
|
|
struct type *repacked_array_type = inner_element_type;
|
|
|
|
|
for (const auto &d : slice_dims)
|
|
|
|
|
{
|
|
|
|
|
/* Create the range. */
|
|
|
|
|
dynamic_prop p_low, p_high, p_stride;
|
|
|
|
|
|
|
|
|
|
p_low.set_const_val (d.low);
|
|
|
|
|
p_high.set_const_val (d.high);
|
|
|
|
|
p_stride.set_const_val (TYPE_LENGTH (repacked_array_type));
|
|
|
|
|
|
|
|
|
|
struct type *new_range
|
|
|
|
|
= create_range_type_with_stride ((struct type *) NULL,
|
|
|
|
|
TYPE_TARGET_TYPE (d.index),
|
|
|
|
|
&p_low, &p_high, 0, &p_stride,
|
|
|
|
|
true);
|
|
|
|
|
repacked_array_type
|
|
|
|
|
= create_array_type (nullptr, repacked_array_type, new_range);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Now copy the elements from the original ARRAY into the packed
|
|
|
|
|
array value DEST. */
|
|
|
|
|
struct value *dest = allocate_value (repacked_array_type);
|
|
|
|
|
if (value_lazy (array)
|
|
|
|
|
|| (total_offset + TYPE_LENGTH (array_slice_type)
|
|
|
|
|
> TYPE_LENGTH (check_typedef (value_type (array)))))
|
|
|
|
|
{
|
|
|
|
|
fortran_array_walker<fortran_lazy_array_repacker_impl> p
|
|
|
|
|
(array_slice_type, value_address (array) + total_offset, dest);
|
|
|
|
|
p.walk ();
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
fortran_array_walker<fortran_array_repacker_impl> p
|
|
|
|
|
(array_slice_type, value_address (array) + total_offset,
|
|
|
|
|
total_offset, array, dest);
|
|
|
|
|
p.walk ();
|
|
|
|
|
}
|
|
|
|
|
array = dest;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (VALUE_LVAL (array) == lval_memory)
|
|
|
|
|
{
|
|
|
|
|
/* If the value we're taking a slice from is not yet loaded, or
|
|
|
|
|
the requested slice is outside the values content range then
|
|
|
|
|
just create a new lazy value pointing at the memory where the
|
|
|
|
|
contents we're looking for exist. */
|
|
|
|
|
if (value_lazy (array)
|
|
|
|
|
|| (total_offset + TYPE_LENGTH (array_slice_type)
|
|
|
|
|
> TYPE_LENGTH (check_typedef (value_type (array)))))
|
|
|
|
|
array = value_at_lazy (array_slice_type,
|
|
|
|
|
value_address (array) + total_offset);
|
|
|
|
|
else
|
|
|
|
|
array = value_from_contents_and_address (array_slice_type,
|
|
|
|
|
(value_contents (array)
|
|
|
|
|
+ total_offset),
|
|
|
|
|
(value_address (array)
|
|
|
|
|
+ total_offset));
|
|
|
|
|
}
|
|
|
|
|
else if (!value_lazy (array))
|
|
|
|
|
array = value_from_component (array, array_slice_type, total_offset);
|
|
|
|
|
else
|
|
|
|
|
error (_("cannot subscript arrays that are not in memory"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return array;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
value *
|
|
|
|
|
fortran_undetermined::evaluate (struct type *expect_type,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
value *callee = std::get<0> (m_storage)->evaluate (nullptr, exp, noside);
|
|
|
|
|
struct type *type = check_typedef (value_type (callee));
|
|
|
|
|
enum type_code code = type->code ();
|
|
|
|
|
|
|
|
|
|
if (code == TYPE_CODE_PTR)
|
|
|
|
|
{
|
|
|
|
|
/* Fortran always passes variable to subroutines as pointer.
|
|
|
|
|
So we need to look into its target type to see if it is
|
|
|
|
|
array, string or function. If it is, we need to switch
|
|
|
|
|
to the target value the original one points to. */
|
|
|
|
|
struct type *target_type = check_typedef (TYPE_TARGET_TYPE (type));
|
|
|
|
|
|
|
|
|
|
if (target_type->code () == TYPE_CODE_ARRAY
|
|
|
|
|
|| target_type->code () == TYPE_CODE_STRING
|
|
|
|
|
|| target_type->code () == TYPE_CODE_FUNC)
|
|
|
|
|
{
|
|
|
|
|
callee = value_ind (callee);
|
|
|
|
|
type = check_typedef (value_type (callee));
|
|
|
|
|
code = type->code ();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
case TYPE_CODE_ARRAY:
|
|
|
|
|
case TYPE_CODE_STRING:
|
|
|
|
|
return value_subarray (callee, exp, noside);
|
|
|
|
|
|
|
|
|
|
case TYPE_CODE_PTR:
|
|
|
|
|
case TYPE_CODE_FUNC:
|
|
|
|
|
case TYPE_CODE_INTERNAL_FUNCTION:
|
|
|
|
|
{
|
|
|
|
|
/* It's a function call. Allocate arg vector, including
|
|
|
|
|
space for the function to be called in argvec[0] and a
|
|
|
|
|
termination NULL. */
|
|
|
|
|
const std::vector<operation_up> &actual (std::get<1> (m_storage));
|
|
|
|
|
std::vector<value *> argvec (actual.size ());
|
|
|
|
|
bool is_internal_func = (code == TYPE_CODE_INTERNAL_FUNCTION);
|
|
|
|
|
for (int tem = 0; tem < argvec.size (); tem++)
|
|
|
|
|
argvec[tem] = fortran_prepare_argument (exp, actual[tem].get (),
|
|
|
|
|
tem, is_internal_func,
|
|
|
|
|
value_type (callee),
|
|
|
|
|
noside);
|
|
|
|
|
return evaluate_subexp_do_call (exp, noside, callee, argvec,
|
|
|
|
|
nullptr, expect_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
error (_("Cannot perform substring on this type"));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
value *
|
|
|
|
|
fortran_bound_1arg::evaluate (struct type *expect_type,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
bool lbound_p = std::get<0> (m_storage) == FORTRAN_LBOUND;
|
|
|
|
|
value *arg1 = std::get<1> (m_storage)->evaluate (nullptr, exp, noside);
|
|
|
|
|
fortran_require_array (value_type (arg1), lbound_p);
|
|
|
|
|
return fortran_bounds_all_dims (lbound_p, exp->gdbarch, arg1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
value *
|
|
|
|
|
fortran_bound_2arg::evaluate (struct type *expect_type,
|
|
|
|
|
struct expression *exp,
|
|
|
|
|
enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
bool lbound_p = std::get<0> (m_storage) == FORTRAN_LBOUND;
|
|
|
|
|
value *arg1 = std::get<1> (m_storage)->evaluate (nullptr, exp, noside);
|
|
|
|
|
fortran_require_array (value_type (arg1), lbound_p);
|
|
|
|
|
|
|
|
|
|
/* User asked for the bounds of a specific dimension of the array. */
|
|
|
|
|
value *arg2 = std::get<2> (m_storage)->evaluate (nullptr, exp, noside);
|
|
|
|
|
struct type *type = check_typedef (value_type (arg2));
|
|
|
|
|
if (type->code () != TYPE_CODE_INT)
|
|
|
|
|
{
|
|
|
|
|
if (lbound_p)
|
|
|
|
|
error (_("LBOUND second argument should be an integer"));
|
|
|
|
|
else
|
|
|
|
|
error (_("UBOUND second argument should be an integer"));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return fortran_bounds_for_dimension (lbound_p, exp->gdbarch, arg1, arg2);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
} /* namespace expr */
|
|
|
|
|
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
/* Special expression lengths for Fortran. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
operator_length_f (const struct expression *exp, int pc, int *oplenp,
|
|
|
|
|
int *argsp)
|
|
|
|
|
{
|
|
|
|
|
int oplen = 1;
|
|
|
|
|
int args = 0;
|
|
|
|
|
|
|
|
|
|
switch (exp->elts[pc - 1].opcode)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
operator_length_standard (exp, pc, oplenp, argsp);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_KIND:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case UNOP_FORTRAN_FLOOR:
|
|
|
|
|
case UNOP_FORTRAN_CEILING:
|
2021-02-11 13:34:06 +00:00
|
|
|
|
case UNOP_FORTRAN_ALLOCATED:
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
oplen = 1;
|
|
|
|
|
args = 1;
|
|
|
|
|
break;
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
|
|
|
|
|
case BINOP_FORTRAN_CMPLX:
|
|
|
|
|
case BINOP_FORTRAN_MODULO:
|
|
|
|
|
oplen = 1;
|
|
|
|
|
args = 2;
|
|
|
|
|
break;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
case FORTRAN_ASSOCIATED:
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_LBOUND:
|
|
|
|
|
case FORTRAN_UBOUND:
|
|
|
|
|
oplen = 3;
|
|
|
|
|
args = longest_to_int (exp->elts[pc - 2].longconst);
|
|
|
|
|
break;
|
|
|
|
|
|
2020-05-07 16:27:16 +01:00
|
|
|
|
case OP_F77_UNDETERMINED_ARGLIST:
|
|
|
|
|
oplen = 3;
|
|
|
|
|
args = 1 + longest_to_int (exp->elts[pc - 2].longconst);
|
|
|
|
|
break;
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*oplenp = oplen;
|
|
|
|
|
*argsp = args;
|
|
|
|
|
}
|
|
|
|
|
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
/* Helper for PRINT_SUBEXP_F. Arguments are as for PRINT_SUBEXP_F, except
|
|
|
|
|
the extra argument NAME which is the text that should be printed as the
|
|
|
|
|
name of this operation. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_unop_subexp_f (struct expression *exp, int *pos,
|
|
|
|
|
struct ui_file *stream, enum precedence prec,
|
|
|
|
|
const char *name)
|
|
|
|
|
{
|
|
|
|
|
(*pos)++;
|
|
|
|
|
fprintf_filtered (stream, "%s(", name);
|
|
|
|
|
print_subexp (exp, pos, stream, PREC_SUFFIX);
|
|
|
|
|
fputs_filtered (")", stream);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Helper for PRINT_SUBEXP_F. Arguments are as for PRINT_SUBEXP_F, except
|
|
|
|
|
the extra argument NAME which is the text that should be printed as the
|
|
|
|
|
name of this operation. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_binop_subexp_f (struct expression *exp, int *pos,
|
|
|
|
|
struct ui_file *stream, enum precedence prec,
|
|
|
|
|
const char *name)
|
|
|
|
|
{
|
|
|
|
|
(*pos)++;
|
|
|
|
|
fprintf_filtered (stream, "%s(", name);
|
|
|
|
|
print_subexp (exp, pos, stream, PREC_SUFFIX);
|
|
|
|
|
fputs_filtered (",", stream);
|
|
|
|
|
print_subexp (exp, pos, stream, PREC_SUFFIX);
|
|
|
|
|
fputs_filtered (")", stream);
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
/* Helper for PRINT_SUBEXP_F. Arguments are as for PRINT_SUBEXP_F, except
|
|
|
|
|
the extra argument NAME which is the text that should be printed as the
|
|
|
|
|
name of this operation. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_unop_or_binop_subexp_f (struct expression *exp, int *pos,
|
|
|
|
|
struct ui_file *stream, enum precedence prec,
|
|
|
|
|
const char *name)
|
|
|
|
|
{
|
|
|
|
|
unsigned nargs = longest_to_int (exp->elts[*pos + 1].longconst);
|
|
|
|
|
(*pos) += 3;
|
|
|
|
|
fprintf_filtered (stream, "%s (", name);
|
|
|
|
|
for (unsigned tem = 0; tem < nargs; tem++)
|
|
|
|
|
{
|
|
|
|
|
if (tem != 0)
|
|
|
|
|
fputs_filtered (", ", stream);
|
|
|
|
|
print_subexp (exp, pos, stream, PREC_ABOVE_COMMA);
|
|
|
|
|
}
|
|
|
|
|
fputs_filtered (")", stream);
|
|
|
|
|
}
|
|
|
|
|
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
/* Special expression printing for Fortran. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_subexp_f (struct expression *exp, int *pos,
|
|
|
|
|
struct ui_file *stream, enum precedence prec)
|
|
|
|
|
{
|
|
|
|
|
int pc = *pos;
|
|
|
|
|
enum exp_opcode op = exp->elts[pc].opcode;
|
|
|
|
|
|
|
|
|
|
switch (op)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
print_subexp_standard (exp, pos, stream, prec);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_KIND:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
print_unop_subexp_f (exp, pos, stream, prec, "KIND");
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_FLOOR:
|
|
|
|
|
print_unop_subexp_f (exp, pos, stream, prec, "FLOOR");
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_CEILING:
|
|
|
|
|
print_unop_subexp_f (exp, pos, stream, prec, "CEILING");
|
|
|
|
|
return;
|
|
|
|
|
|
2021-02-11 13:34:06 +00:00
|
|
|
|
case UNOP_FORTRAN_ALLOCATED:
|
|
|
|
|
print_unop_subexp_f (exp, pos, stream, prec, "ALLOCATED");
|
|
|
|
|
return;
|
|
|
|
|
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_FORTRAN_CMPLX:
|
|
|
|
|
print_binop_subexp_f (exp, pos, stream, prec, "CMPLX");
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case BINOP_FORTRAN_MODULO:
|
|
|
|
|
print_binop_subexp_f (exp, pos, stream, prec, "MODULO");
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
return;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
case FORTRAN_ASSOCIATED:
|
|
|
|
|
print_unop_or_binop_subexp_f (exp, pos, stream, prec, "ASSOCIATED");
|
|
|
|
|
return;
|
|
|
|
|
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_LBOUND:
|
2021-02-24 12:50:00 +00:00
|
|
|
|
print_unop_or_binop_subexp_f (exp, pos, stream, prec, "LBOUND");
|
|
|
|
|
return;
|
|
|
|
|
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_UBOUND:
|
2021-02-24 12:50:00 +00:00
|
|
|
|
print_unop_or_binop_subexp_f (exp, pos, stream, prec, "UBOUND");
|
|
|
|
|
return;
|
2021-02-09 15:46:13 +00:00
|
|
|
|
|
2020-05-07 16:27:16 +01:00
|
|
|
|
case OP_F77_UNDETERMINED_ARGLIST:
|
gdb: fix debug expression dumping of function call expressions
In commit:
commit 6d81691950f8c4be4a49a85a672255c140e82468
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
2020-11-06 13:40:22 +00:00
|
|
|
|
(*pos)++;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
print_subexp_funcall (exp, pos, stream);
|
|
|
|
|
return;
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Special expression dumping for Fortran. */
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
dump_subexp_body_f (struct expression *exp,
|
|
|
|
|
struct ui_file *stream, int elt)
|
|
|
|
|
{
|
|
|
|
|
int opcode = exp->elts[elt].opcode;
|
|
|
|
|
int oplen, nargs, i;
|
|
|
|
|
|
|
|
|
|
switch (opcode)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
return dump_subexp_body_standard (exp, stream, elt);
|
|
|
|
|
|
|
|
|
|
case UNOP_FORTRAN_KIND:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case UNOP_FORTRAN_FLOOR:
|
|
|
|
|
case UNOP_FORTRAN_CEILING:
|
2021-02-11 13:34:06 +00:00
|
|
|
|
case UNOP_FORTRAN_ALLOCATED:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_FORTRAN_CMPLX:
|
|
|
|
|
case BINOP_FORTRAN_MODULO:
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
operator_length_f (exp, (elt + 1), &oplen, &nargs);
|
|
|
|
|
break;
|
2020-05-07 16:27:16 +01:00
|
|
|
|
|
2021-02-24 12:50:00 +00:00
|
|
|
|
case FORTRAN_ASSOCIATED:
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_LBOUND:
|
|
|
|
|
case FORTRAN_UBOUND:
|
|
|
|
|
operator_length_f (exp, (elt + 3), &oplen, &nargs);
|
|
|
|
|
break;
|
|
|
|
|
|
2020-05-07 16:27:16 +01:00
|
|
|
|
case OP_F77_UNDETERMINED_ARGLIST:
|
gdb: fix debug expression dumping of function call expressions
In commit:
commit 6d81691950f8c4be4a49a85a672255c140e82468
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
2020-11-06 13:40:22 +00:00
|
|
|
|
return dump_subexp_body_funcall (exp, stream, elt + 1);
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
elt += oplen;
|
|
|
|
|
for (i = 0; i < nargs; i += 1)
|
|
|
|
|
elt = dump_subexp (exp, stream, elt);
|
|
|
|
|
|
|
|
|
|
return elt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Special expression checking for Fortran. */
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
operator_check_f (struct expression *exp, int pos,
|
|
|
|
|
int (*objfile_func) (struct objfile *objfile,
|
|
|
|
|
void *data),
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
|
|
|
|
const union exp_element *const elts = exp->elts;
|
|
|
|
|
|
|
|
|
|
switch (elts[pos].opcode)
|
|
|
|
|
{
|
|
|
|
|
case UNOP_FORTRAN_KIND:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case UNOP_FORTRAN_FLOOR:
|
|
|
|
|
case UNOP_FORTRAN_CEILING:
|
2021-02-11 13:34:06 +00:00
|
|
|
|
case UNOP_FORTRAN_ALLOCATED:
|
gdb/fortran: Additional builtin procedures
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
2019-02-13 17:10:18 +00:00
|
|
|
|
case BINOP_FORTRAN_CMPLX:
|
|
|
|
|
case BINOP_FORTRAN_MODULO:
|
2021-02-24 12:50:00 +00:00
|
|
|
|
case FORTRAN_ASSOCIATED:
|
2021-02-09 15:46:13 +00:00
|
|
|
|
case FORTRAN_LBOUND:
|
|
|
|
|
case FORTRAN_UBOUND:
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
/* Any references to objfiles are held in the arguments to this
|
|
|
|
|
expression, not within the expression itself, so no additional
|
|
|
|
|
checking is required here, the outer expression iteration code
|
|
|
|
|
will take care of checking each argument. */
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
return operator_check_standard (exp, pos, objfile_func, data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-16 16:16:59 +00:00
|
|
|
|
/* Expression processing for Fortran. */
|
2020-09-16 16:27:30 +01:00
|
|
|
|
const struct exp_descriptor f_language::exp_descriptor_tab =
|
2019-01-16 16:16:59 +00:00
|
|
|
|
{
|
gdb/fortran: Introduce fortran-operator.def file
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6c4 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
2019-04-01 21:01:09 +01:00
|
|
|
|
print_subexp_f,
|
|
|
|
|
operator_length_f,
|
|
|
|
|
operator_check_f,
|
|
|
|
|
dump_subexp_body_f,
|
2019-01-16 16:16:59 +00:00
|
|
|
|
evaluate_subexp_f
|
|
|
|
|
};
|
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
/* See language.h. */
|
gdb: Represent all languages as sub-classes of language_defn
This commit converts all languages to sub-classes of a language_defn
base class.
The motivation for this change is to make it easier to add new methods
onto languages without having to update all of the individual language
structures. In the future it might be possible to move more things,
like expression parsing, into the language class(es) for better
encapsulation, however I have no plans to tackle this in the short
term.
This commit sets up a strategy for transitioning from the current
language system, where each language is an instance of the
language_defn structure, to the class hierarchy system.
The plan is to rename the existing language_defn into language_data,
and make this a base class for the new language_defn class, something
like this:
struct language_data
{
... old language_defn fields here ...
};
struct language_defn : public language_data
{
language_defn (const language_data d)
: language_data (d)
{ .... }
};
Then each existing language, for example ada_language_defn can be
converted into an instance of language_data, and passed into the
constructor of a new language class, something like this:
language_data ada_language_data =
{
... old ada_language_defn values here ...
};
struct ada_language : public language_defn
{
ada_language (ada_language_data)
{ .... }
};
What this means is that immediately after the conversion nothing much
changes. Every language is now its own class, but all the old
language fields still exist and can be accessed in the same way.
In later commits I will convert function pointers from the old
language_defn structure into real class methods on language_defn, with
overrides on sub-classes where needed.
At this point I imagine that those fields of the old language_defn
structure that contained only data will probably remain as data fields
within the new language_data base structure, it is only the methods
that I plan to change initially.
I tweaked how we manage the list of languages a bit, each language is
now registered as it is created, and this resulted in a small number
of changes in language.c.
Most of the changes in the *-lang.c files are identical.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* gdb/ada-lang.c (ada_language_defn): Convert to...
(ada_language_data): ...this.
(class ada_language): New class.
(ada_language_defn): New static global.
* gdb/c-lang.c (c_language_defn): Convert to...
(c_language_data): ...this.
(class c_language): New class.
(c_language_defn): New static global.
(cplus_language_defn): Convert to...
(cplus_language_data): ...this.
(class cplus_language): New class.
(cplus_language_defn): New static global.
(asm_language_defn): Convert to...
(asm_language_data): ...this.
(class asm_language): New class.
(asm_language_defn): New static global.
(minimal_language_defn): Convert to...
(minimal_language_data): ...this.
(class minimal_language): New class.
(minimal_language_defn): New static global.
* gdb/d-lang.c (d_language_defn): Convert to...
(d_language_data): ...this.
(class d_language): New class.
(d_language_defn): New static global.
* gdb/f-lang.c (f_language_defn): Convert to...
(f_language_data): ...this.
(class f_language): New class.
(f_language_defn): New static global.
* gdb/go-lang.c (go_language_defn): Convert to...
(go_language_data): ...this.
(class go_language): New class.
(go_language_defn): New static global.
* gdb/language.c (unknown_language_defn): Remove declaration.
(current_language): Initialize to nullptr, real initialization is
moved to _initialize_language.
(languages): Delete global.
(language_defn::languages): Define.
(set_language_command): Use language_defn::languages.
(set_language): Likewise.
(range_error): Likewise.
(language_enum): Likewise.
(language_def): Likewise.
(add_set_language_command): Use language_def::languages for the
language list, and language_def to lookup language pointers.
(skip_language_trampoline): Use language_defn::languages.
(unknown_language_defn): Convert to...
(unknown_language_data): ...this.
(class unknown_language): New class.
(unknown_language_defn): New static global.
(auto_language_defn): Convert to...
(auto_language_data): ...this.
(class auto_language): New class.
(auto_language_defn): New static global.
(language_gdbarch_post_init): Use language_defn::languages.
(_initialize_language): Initialize current_language.
* gdb/language.h (struct language_defn): Rename to...
(struct language_data): ...this.
(struct language_defn): New.
(auto_language_defn): Delete.
(unknown_language_defn): Delete.
(minimal_language_defn): Delete.
(ada_language_defn): Delete.
(asm_language_defn): Delete.
(c_language_defn): Delete.
(cplus_language_defn): Delete.
(d_language_defn): Delete.
(f_language_defn): Delete.
(go_language_defn): Delete.
(m2_language_defn): Delete.
(objc_language_defn): Delete.
(opencl_language_defn): Delete.
(pascal_language_defn): Delete.
(rust_language_defn): Delete.
* gdb/m2-lang.c (m2_language_defn): Convert to...
(m2_language_data): ...this.
(class m2_language): New class.
(m2_language_defn): New static global.
* gdb/objc-lang.c (objc_language_defn): Convert to...
(objc_language_data): ...this.
(class objc_language): New class.
(objc_language_defn): New static global.
* gdb/opencl-lang.c (opencl_language_defn): Convert to...
(opencl_language_data): ...this.
(class opencl_language): New class.
(opencl_language_defn): New static global.
* gdb/p-lang.c (pascal_language_defn): Convert to...
(pascal_language_data): ...this.
(class pascal_language): New class.
(pascal_language_defn): New static global.
* gdb/rust-exp.y (rust_lex_tests): Use language_def to find
language pointer, update comment format.
* gdb/rust-lang.c (rust_language_defn): Convert to...
(rust_language_data): ...this.
(class rust_language): New class.
(rust_language_defn): New static global.
2020-05-01 12:16:58 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
void
|
|
|
|
|
f_language::language_arch_info (struct gdbarch *gdbarch,
|
|
|
|
|
struct language_arch_info *lai) const
|
gdb: Represent all languages as sub-classes of language_defn
This commit converts all languages to sub-classes of a language_defn
base class.
The motivation for this change is to make it easier to add new methods
onto languages without having to update all of the individual language
structures. In the future it might be possible to move more things,
like expression parsing, into the language class(es) for better
encapsulation, however I have no plans to tackle this in the short
term.
This commit sets up a strategy for transitioning from the current
language system, where each language is an instance of the
language_defn structure, to the class hierarchy system.
The plan is to rename the existing language_defn into language_data,
and make this a base class for the new language_defn class, something
like this:
struct language_data
{
... old language_defn fields here ...
};
struct language_defn : public language_data
{
language_defn (const language_data d)
: language_data (d)
{ .... }
};
Then each existing language, for example ada_language_defn can be
converted into an instance of language_data, and passed into the
constructor of a new language class, something like this:
language_data ada_language_data =
{
... old ada_language_defn values here ...
};
struct ada_language : public language_defn
{
ada_language (ada_language_data)
{ .... }
};
What this means is that immediately after the conversion nothing much
changes. Every language is now its own class, but all the old
language fields still exist and can be accessed in the same way.
In later commits I will convert function pointers from the old
language_defn structure into real class methods on language_defn, with
overrides on sub-classes where needed.
At this point I imagine that those fields of the old language_defn
structure that contained only data will probably remain as data fields
within the new language_data base structure, it is only the methods
that I plan to change initially.
I tweaked how we manage the list of languages a bit, each language is
now registered as it is created, and this resulted in a small number
of changes in language.c.
Most of the changes in the *-lang.c files are identical.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* gdb/ada-lang.c (ada_language_defn): Convert to...
(ada_language_data): ...this.
(class ada_language): New class.
(ada_language_defn): New static global.
* gdb/c-lang.c (c_language_defn): Convert to...
(c_language_data): ...this.
(class c_language): New class.
(c_language_defn): New static global.
(cplus_language_defn): Convert to...
(cplus_language_data): ...this.
(class cplus_language): New class.
(cplus_language_defn): New static global.
(asm_language_defn): Convert to...
(asm_language_data): ...this.
(class asm_language): New class.
(asm_language_defn): New static global.
(minimal_language_defn): Convert to...
(minimal_language_data): ...this.
(class minimal_language): New class.
(minimal_language_defn): New static global.
* gdb/d-lang.c (d_language_defn): Convert to...
(d_language_data): ...this.
(class d_language): New class.
(d_language_defn): New static global.
* gdb/f-lang.c (f_language_defn): Convert to...
(f_language_data): ...this.
(class f_language): New class.
(f_language_defn): New static global.
* gdb/go-lang.c (go_language_defn): Convert to...
(go_language_data): ...this.
(class go_language): New class.
(go_language_defn): New static global.
* gdb/language.c (unknown_language_defn): Remove declaration.
(current_language): Initialize to nullptr, real initialization is
moved to _initialize_language.
(languages): Delete global.
(language_defn::languages): Define.
(set_language_command): Use language_defn::languages.
(set_language): Likewise.
(range_error): Likewise.
(language_enum): Likewise.
(language_def): Likewise.
(add_set_language_command): Use language_def::languages for the
language list, and language_def to lookup language pointers.
(skip_language_trampoline): Use language_defn::languages.
(unknown_language_defn): Convert to...
(unknown_language_data): ...this.
(class unknown_language): New class.
(unknown_language_defn): New static global.
(auto_language_defn): Convert to...
(auto_language_data): ...this.
(class auto_language): New class.
(auto_language_defn): New static global.
(language_gdbarch_post_init): Use language_defn::languages.
(_initialize_language): Initialize current_language.
* gdb/language.h (struct language_defn): Rename to...
(struct language_data): ...this.
(struct language_defn): New.
(auto_language_defn): Delete.
(unknown_language_defn): Delete.
(minimal_language_defn): Delete.
(ada_language_defn): Delete.
(asm_language_defn): Delete.
(c_language_defn): Delete.
(cplus_language_defn): Delete.
(d_language_defn): Delete.
(f_language_defn): Delete.
(go_language_defn): Delete.
(m2_language_defn): Delete.
(objc_language_defn): Delete.
(opencl_language_defn): Delete.
(pascal_language_defn): Delete.
(rust_language_defn): Delete.
* gdb/m2-lang.c (m2_language_defn): Convert to...
(m2_language_data): ...this.
(class m2_language): New class.
(m2_language_defn): New static global.
* gdb/objc-lang.c (objc_language_defn): Convert to...
(objc_language_data): ...this.
(class objc_language): New class.
(objc_language_defn): New static global.
* gdb/opencl-lang.c (opencl_language_defn): Convert to...
(opencl_language_data): ...this.
(class opencl_language): New class.
(opencl_language_defn): New static global.
* gdb/p-lang.c (pascal_language_defn): Convert to...
(pascal_language_data): ...this.
(class pascal_language): New class.
(pascal_language_defn): New static global.
* gdb/rust-exp.y (rust_lex_tests): Use language_def to find
language pointer, update comment format.
* gdb/rust-lang.c (rust_language_defn): Convert to...
(rust_language_data): ...this.
(class rust_language): New class.
(rust_language_defn): New static global.
2020-05-01 12:16:58 +01:00
|
|
|
|
{
|
2020-09-16 16:27:30 +01:00
|
|
|
|
const struct builtin_f_type *builtin = builtin_f_type (gdbarch);
|
|
|
|
|
|
gdb: rewrite how per language primitive types are managed
Consider the following GDB session:
$ gdb
(gdb) set language c
(gdb) ptype void
type = void
(gdb) set language fortran
(gdb) ptype void
No symbol table is loaded. Use the "file" command.
(gdb)
With no symbol file loaded GDB and the language set to C GDB knows
about the type void, while when the language is set to Fortran GDB
doesn't know about the void, why is that?
In f-lang.c, f_language::language_arch_info, we do have this line:
lai->primitive_type_vector [f_primitive_type_void]
= builtin->builtin_void;
where we add the void type to the list of primitive types that GDB
should always know about, so what's going wrong?
It turns out that the primitive types are stored in a C style array,
indexed by an enum, so Fortran uses `enum f_primitive_types'. The
array is allocated and populated in each languages language_arch_info
member function. The array is allocated with an extra entry at the
end which is left as a NULL value, and this indicates the end of the
array of types.
Unfortunately for Fortran, a type is not assigned for each element in
the enum. As a result the final populated array has gaps in it, gaps
which are initialised to NULL, and so every time we iterate over the
list (for Fortran) we stop early, and never reach the void type.
This has been the case since 2007 when this functionality was added to
GDB in commit cad351d11d6c3f6487cd.
Obviously I could just fix Fortran by ensuring that either the enum is
trimmed, or we create types for the missing types. However, I think a
better approach would be to move to C++ data structures and removed
the fixed enum indexing into the array approach.
After this commit the primitive types are pushed into a vector, and
GDB just iterates over the vector in the obvious way when it needs to
hunt for a type. After this commit all the currently defined
primitive types can be found when the language is set to Fortran, for
example:
$ gdb
(gdb) set language fortran
(gdb) ptype void
type = void
(gdb)
A new test checks this functionality.
I didn't see any other languages with similar issues, but I could have
missed something.
gdb/ChangeLog:
* ada-exp.y (find_primitive_type): Make parameter const.
* ada-lang.c (enum ada_primitive_types): Delete.
(ada_language::language_arch_info): Update.
* c-lang.c (enum c_primitive_types): Delete.
(c_language_arch_info): Update.
(enum cplus_primitive_types): Delete.
(cplus_language::language_arch_info): Update.
* d-lang.c (enum d_primitive_types): Delete.
(d_language::language_arch_info): Update.
* f-lang.c (enum f_primitive_types): Delete.
(f_language::language_arch_info): Update.
* go-lang.c (enum go_primitive_types): Delete.
(go_language::language_arch_info): Update.
* language.c (auto_or_unknown_language::language_arch_info):
Update.
(language_gdbarch_post_init): Use obstack_new, use array indexing.
(language_string_char_type): Add header comment, call function in
language_arch_info.
(language_bool_type): Likewise
(language_arch_info::bool_type): Define.
(language_lookup_primitive_type_1): Delete.
(language_lookup_primitive_type): Rewrite as a templated function
to call function in language_arch_info, then instantiate twice.
(language_arch_info::type_and_symbol::alloc_type_symbol): Define.
(language_arch_info::lookup_primitive_type_and_symbol): Define.
(language_arch_info::lookup_primitive_type): Define twice with
different signatures.
(language_arch_info::lookup_primitive_type_as_symbol): Define.
(language_lookup_primitive_type_as_symbol): Rewrite to call a
member function in language_arch_info.
* language.h (language_arch_info): Complete rewrite.
(language_lookup_primitive_type): Make templated.
* m2-lang.c (enum m2_primitive_types): Delete.
(m2_language::language_arch_info): Update.
* opencl-lang.c (OCL_P_TYPE): Delete.
(enum opencl_primitive_types): Delete.
(opencl_type_data): Delete.
(builtin_opencl_type): Delete.
(lookup_opencl_vector_type): Update.
(opencl_language::language_arch_info): Update, lots of content
moved from...
(build_opencl_types): ...here. This function is now deleted.
(_initialize_opencl_language): Delete.
* p-lang.c (enum pascal_primitive_types): Delete.
(pascal_language::language_arch_info): Update.
* rust-lang.c (enum rust_primitive_types): Delete.
(rust_language::language_arch_info): Update.
gdb/testsuite/ChangeLog:
* gdb.fortran/types.exp: Add more tests.
2020-10-30 20:40:59 +00:00
|
|
|
|
/* Helper function to allow shorter lines below. */
|
|
|
|
|
auto add = [&] (struct type * t)
|
|
|
|
|
{
|
|
|
|
|
lai->add_primitive_type (t);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
add (builtin->builtin_character);
|
|
|
|
|
add (builtin->builtin_logical);
|
|
|
|
|
add (builtin->builtin_logical_s1);
|
|
|
|
|
add (builtin->builtin_logical_s2);
|
|
|
|
|
add (builtin->builtin_logical_s8);
|
|
|
|
|
add (builtin->builtin_real);
|
|
|
|
|
add (builtin->builtin_real_s8);
|
|
|
|
|
add (builtin->builtin_real_s16);
|
|
|
|
|
add (builtin->builtin_complex_s8);
|
|
|
|
|
add (builtin->builtin_complex_s16);
|
|
|
|
|
add (builtin->builtin_void);
|
|
|
|
|
|
|
|
|
|
lai->set_string_char_type (builtin->builtin_character);
|
|
|
|
|
lai->set_bool_type (builtin->builtin_logical_s2, "logical");
|
2020-09-16 16:27:30 +01:00
|
|
|
|
}
|
2020-08-04 16:31:56 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
/* See language.h. */
|
2020-08-04 16:31:56 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
unsigned int
|
|
|
|
|
f_language::search_name_hash (const char *name) const
|
|
|
|
|
{
|
|
|
|
|
return cp_search_name_hash (name);
|
|
|
|
|
}
|
2020-08-04 17:07:59 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
/* See language.h. */
|
2020-08-04 17:07:59 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
struct block_symbol
|
|
|
|
|
f_language::lookup_symbol_nonlocal (const char *name,
|
|
|
|
|
const struct block *block,
|
|
|
|
|
const domain_enum domain) const
|
|
|
|
|
{
|
|
|
|
|
return cp_lookup_symbol_nonlocal (this, name, block, domain);
|
|
|
|
|
}
|
2020-06-01 11:46:54 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
/* See language.h. */
|
2020-06-01 11:46:54 +01:00
|
|
|
|
|
2020-09-16 16:27:30 +01:00
|
|
|
|
symbol_name_matcher_ftype *
|
|
|
|
|
f_language::get_symbol_name_matcher_inner
|
|
|
|
|
(const lookup_name_info &lookup_name) const
|
|
|
|
|
{
|
|
|
|
|
return cp_get_symbol_name_matcher (lookup_name);
|
|
|
|
|
}
|
gdb: Represent all languages as sub-classes of language_defn
This commit converts all languages to sub-classes of a language_defn
base class.
The motivation for this change is to make it easier to add new methods
onto languages without having to update all of the individual language
structures. In the future it might be possible to move more things,
like expression parsing, into the language class(es) for better
encapsulation, however I have no plans to tackle this in the short
term.
This commit sets up a strategy for transitioning from the current
language system, where each language is an instance of the
language_defn structure, to the class hierarchy system.
The plan is to rename the existing language_defn into language_data,
and make this a base class for the new language_defn class, something
like this:
struct language_data
{
... old language_defn fields here ...
};
struct language_defn : public language_data
{
language_defn (const language_data d)
: language_data (d)
{ .... }
};
Then each existing language, for example ada_language_defn can be
converted into an instance of language_data, and passed into the
constructor of a new language class, something like this:
language_data ada_language_data =
{
... old ada_language_defn values here ...
};
struct ada_language : public language_defn
{
ada_language (ada_language_data)
{ .... }
};
What this means is that immediately after the conversion nothing much
changes. Every language is now its own class, but all the old
language fields still exist and can be accessed in the same way.
In later commits I will convert function pointers from the old
language_defn structure into real class methods on language_defn, with
overrides on sub-classes where needed.
At this point I imagine that those fields of the old language_defn
structure that contained only data will probably remain as data fields
within the new language_data base structure, it is only the methods
that I plan to change initially.
I tweaked how we manage the list of languages a bit, each language is
now registered as it is created, and this resulted in a small number
of changes in language.c.
Most of the changes in the *-lang.c files are identical.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* gdb/ada-lang.c (ada_language_defn): Convert to...
(ada_language_data): ...this.
(class ada_language): New class.
(ada_language_defn): New static global.
* gdb/c-lang.c (c_language_defn): Convert to...
(c_language_data): ...this.
(class c_language): New class.
(c_language_defn): New static global.
(cplus_language_defn): Convert to...
(cplus_language_data): ...this.
(class cplus_language): New class.
(cplus_language_defn): New static global.
(asm_language_defn): Convert to...
(asm_language_data): ...this.
(class asm_language): New class.
(asm_language_defn): New static global.
(minimal_language_defn): Convert to...
(minimal_language_data): ...this.
(class minimal_language): New class.
(minimal_language_defn): New static global.
* gdb/d-lang.c (d_language_defn): Convert to...
(d_language_data): ...this.
(class d_language): New class.
(d_language_defn): New static global.
* gdb/f-lang.c (f_language_defn): Convert to...
(f_language_data): ...this.
(class f_language): New class.
(f_language_defn): New static global.
* gdb/go-lang.c (go_language_defn): Convert to...
(go_language_data): ...this.
(class go_language): New class.
(go_language_defn): New static global.
* gdb/language.c (unknown_language_defn): Remove declaration.
(current_language): Initialize to nullptr, real initialization is
moved to _initialize_language.
(languages): Delete global.
(language_defn::languages): Define.
(set_language_command): Use language_defn::languages.
(set_language): Likewise.
(range_error): Likewise.
(language_enum): Likewise.
(language_def): Likewise.
(add_set_language_command): Use language_def::languages for the
language list, and language_def to lookup language pointers.
(skip_language_trampoline): Use language_defn::languages.
(unknown_language_defn): Convert to...
(unknown_language_data): ...this.
(class unknown_language): New class.
(unknown_language_defn): New static global.
(auto_language_defn): Convert to...
(auto_language_data): ...this.
(class auto_language): New class.
(auto_language_defn): New static global.
(language_gdbarch_post_init): Use language_defn::languages.
(_initialize_language): Initialize current_language.
* gdb/language.h (struct language_defn): Rename to...
(struct language_data): ...this.
(struct language_defn): New.
(auto_language_defn): Delete.
(unknown_language_defn): Delete.
(minimal_language_defn): Delete.
(ada_language_defn): Delete.
(asm_language_defn): Delete.
(c_language_defn): Delete.
(cplus_language_defn): Delete.
(d_language_defn): Delete.
(f_language_defn): Delete.
(go_language_defn): Delete.
(m2_language_defn): Delete.
(objc_language_defn): Delete.
(opencl_language_defn): Delete.
(pascal_language_defn): Delete.
(rust_language_defn): Delete.
* gdb/m2-lang.c (m2_language_defn): Convert to...
(m2_language_data): ...this.
(class m2_language): New class.
(m2_language_defn): New static global.
* gdb/objc-lang.c (objc_language_defn): Convert to...
(objc_language_data): ...this.
(class objc_language): New class.
(objc_language_defn): New static global.
* gdb/opencl-lang.c (opencl_language_defn): Convert to...
(opencl_language_data): ...this.
(class opencl_language): New class.
(opencl_language_defn): New static global.
* gdb/p-lang.c (pascal_language_defn): Convert to...
(pascal_language_data): ...this.
(class pascal_language): New class.
(pascal_language_defn): New static global.
* gdb/rust-exp.y (rust_lex_tests): Use language_def to find
language pointer, update comment format.
* gdb/rust-lang.c (rust_language_defn): Convert to...
(rust_language_data): ...this.
(class rust_language): New class.
(rust_language_defn): New static global.
2020-05-01 12:16:58 +01:00
|
|
|
|
|
|
|
|
|
/* Single instance of the Fortran language class. */
|
|
|
|
|
|
|
|
|
|
static f_language f_language_defn;
|
|
|
|
|
|
* gdbtypes.h (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Replace global
variable declaration with compatibility macro.
(struct builtin_f_type): New data type.
(builtin_f_type): Add prototype.
* f-lang.c (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Remove variables.
(f_language_arch_info): Use builtin_f_type instead of variables.
(build_fortran_types): Build builtin_f_type structure instead of
setting global type variables.
(f_type_data): New variable.
(builtin_f_type): New function.
(_initialize_f_language): Do not call build_fortran_types. Do not
swap global type variables. Register f_type_data per-gdbarch data.
2007-06-16 20:09:07 +00:00
|
|
|
|
static void *
|
|
|
|
|
build_fortran_types (struct gdbarch *gdbarch)
|
1999-04-16 01:35:26 +00:00
|
|
|
|
{
|
* gdbtypes.h (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Replace global
variable declaration with compatibility macro.
(struct builtin_f_type): New data type.
(builtin_f_type): Add prototype.
* f-lang.c (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Remove variables.
(f_language_arch_info): Use builtin_f_type instead of variables.
(build_fortran_types): Build builtin_f_type structure instead of
setting global type variables.
(f_type_data): New variable.
(builtin_f_type): New function.
(_initialize_f_language): Do not call build_fortran_types. Do not
swap global type variables. Register f_type_data per-gdbarch data.
2007-06-16 20:09:07 +00:00
|
|
|
|
struct builtin_f_type *builtin_f_type
|
|
|
|
|
= GDBARCH_OBSTACK_ZALLOC (gdbarch, struct builtin_f_type);
|
|
|
|
|
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
builtin_f_type->builtin_void
|
2019-02-16 16:39:29 +00:00
|
|
|
|
= arch_type (gdbarch, TYPE_CODE_VOID, TARGET_CHAR_BIT, "void");
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_character
|
2019-01-18 11:24:24 +00:00
|
|
|
|
= arch_type (gdbarch, TYPE_CODE_CHAR, TARGET_CHAR_BIT, "character");
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_logical_s1
|
|
|
|
|
= arch_boolean_type (gdbarch, TARGET_CHAR_BIT, 1, "logical*1");
|
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_integer_s2
|
|
|
|
|
= arch_integer_type (gdbarch, gdbarch_short_bit (gdbarch), 0,
|
|
|
|
|
"integer*2");
|
|
|
|
|
|
2019-01-17 16:31:56 +00:00
|
|
|
|
builtin_f_type->builtin_integer_s8
|
|
|
|
|
= arch_integer_type (gdbarch, gdbarch_long_long_bit (gdbarch), 0,
|
|
|
|
|
"integer*8");
|
|
|
|
|
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
builtin_f_type->builtin_logical_s2
|
|
|
|
|
= arch_boolean_type (gdbarch, gdbarch_short_bit (gdbarch), 1,
|
|
|
|
|
"logical*2");
|
|
|
|
|
|
2010-04-20 17:22:19 +00:00
|
|
|
|
builtin_f_type->builtin_logical_s8
|
|
|
|
|
= arch_boolean_type (gdbarch, gdbarch_long_long_bit (gdbarch), 1,
|
|
|
|
|
"logical*8");
|
|
|
|
|
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
builtin_f_type->builtin_integer
|
|
|
|
|
= arch_integer_type (gdbarch, gdbarch_int_bit (gdbarch), 0,
|
|
|
|
|
"integer");
|
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_logical
|
|
|
|
|
= arch_boolean_type (gdbarch, gdbarch_int_bit (gdbarch), 1,
|
|
|
|
|
"logical*4");
|
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_real
|
|
|
|
|
= arch_float_type (gdbarch, gdbarch_float_bit (gdbarch),
|
2016-09-06 17:31:03 +02:00
|
|
|
|
"real", gdbarch_float_format (gdbarch));
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
builtin_f_type->builtin_real_s8
|
|
|
|
|
= arch_float_type (gdbarch, gdbarch_double_bit (gdbarch),
|
2016-09-06 17:31:03 +02:00
|
|
|
|
"real*8", gdbarch_double_format (gdbarch));
|
2019-05-03 15:23:55 +01:00
|
|
|
|
auto fmt = gdbarch_floatformat_for_type (gdbarch, "real(kind=16)", 128);
|
2019-05-21 22:14:05 +01:00
|
|
|
|
if (fmt != nullptr)
|
|
|
|
|
builtin_f_type->builtin_real_s16
|
|
|
|
|
= arch_float_type (gdbarch, 128, "real*16", fmt);
|
|
|
|
|
else if (gdbarch_long_double_bit (gdbarch) == 128)
|
|
|
|
|
builtin_f_type->builtin_real_s16
|
|
|
|
|
= arch_float_type (gdbarch, gdbarch_long_double_bit (gdbarch),
|
|
|
|
|
"real*16", gdbarch_long_double_format (gdbarch));
|
|
|
|
|
else
|
|
|
|
|
builtin_f_type->builtin_real_s16
|
|
|
|
|
= arch_type (gdbarch, TYPE_CODE_ERROR, 128, "real*16");
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
|
|
|
|
|
builtin_f_type->builtin_complex_s8
|
2020-04-01 14:09:52 -06:00
|
|
|
|
= init_complex_type ("complex*8", builtin_f_type->builtin_real);
|
* gdbtypes.h (TYPE_OBJFILE_OWNED, TYPE_OWNER): New macros.
(TYPE_OBJFILE, TYPE_ALLOC, TYPE_ZALLOC): Reimplement.
(alloc_type_arch): Add prototype.
(alloc_type_copy): Likewise.
(get_type_arch): Likewise.
(arch_type): Likewise.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
* gdbtypes.c (alloc_type): No longer support NULL objfile.
(init_type): Likewise.
(alloc_type_arch): New function.
(alloc_type_copy): New function.
(get_type_arch): New function.
(smash_type): Preserve type ownership information.
(make_pointer_type, make_reference_type, make_function_type,
smash_to_memberptr_type, smash_to_method_type): No longer
preserve OBJFILE across smash_type calls.
(make_pointer_type, make_reference_type, make_function_type,
lookup_memberptr_type, lookup_methodptr_type, allocate_stub_method,
create_range_type, create_array_type, create_set_type, copy_type):
Use alloc_type_copy when allocating types.
(check_typedef): Use alloc_type_arch.
(copy_type_recursive): Likewise. Preserve type ownership data
after copying type.
(recursive_dump_type): Dump type ownership data.
(alloc_type_instance): Update type ownership check.
(copy_type, copy_type_recursive): Likewise.
(arch_type): New function.
(arch_integer_type): Likewise.
(arch_character_type): Likewise.
(arch_boolean_type): Likewise.
(init_float_type): Remove, replace by ...
(arch_float_type): ... this.
(init_complex_type): Remove, replace by ...
(arch_complex_type): ... this.
(init_flags_type): Remove, replace by ...
(arch_flags_type): ... this.
(append_flags_type_flag): Move down.
(init_composite_type): Remove, replace by ...
(arch_composite_type): ... this.
(append_composite_type_field_aligned,
append_composite_type_field): Move down.
* gdbarch.c (gdbtypes_post_init): Allocate all types
using per-architecture routines.
* ada-lang.c (ada_language_arch_info): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* jv-lang.c (build_java_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* scm-lang.c (build_scm_types): Likewise.
* ada-lang.c (ada_type_of_array): Use alloc_type_copy.
(packed_array_type): Likewise.
(ada_template_to_fixed_record_type_1): Likewise.
(template_to_static_fixed_type): Likewise.
(to_record_with_fixed_variant_part): Likewise.
(to_fixed_variant_branch_type): Likewise.
(to_fixed_array_type): Likewise.
(to_fixed_range_type): Likewise.
(empty_record): Use type instead of objfile argument.
Use alloc_type_copy.
(to_fixed_variant_branch_type): Update call to empty_record.
* jv-lang.c (type_from_class): Use alloc_type_arch.
* arm-tdep.c (arm_ext_type): Allocate per-architecture type.
* i386-tdep.c (i386_eflags_type, i386_mxcsr_type, i387_ext_type,
i386_mmx_type, i386_sse_type): Likewise.
* ia64-tdep.c (ia64_ext_type): Likewise.
* m32c-tdep.c (make_types): Likewise.
* m68k-tdep.c (m68k_ps_type, m68881_ext_type): Likewise.
* rs6000-tdep.c (rs6000_builtin_type_vec64,
rs6000_builtin_type_vec128): Likewise.
* sparc-tdep.c (sparc_psr_type, sparc_fsr_type): Likewise.
* sparc64-tdep.c (sparc64_pstate_type, sparc64_fsr_type,
sparc64_fprs_type): Likewise.
* spu-tdep.c (spu_builtin_type_vec128): Likewise.
* xtensa-tdep.c (xtensa_register_type): Likewise.
* linux-tdep.c (linux_get_siginfo_type): Likewise.
* target-descriptions.c (tdesc_gdb_type): Likewise.
* gnu-v3-abi.c (build_gdb_vtable_type): Likewise.
2009-07-02 12:55:30 +00:00
|
|
|
|
builtin_f_type->builtin_complex_s16
|
2020-04-01 14:09:52 -06:00
|
|
|
|
= init_complex_type ("complex*16", builtin_f_type->builtin_real_s8);
|
2020-04-02 13:13:02 -06:00
|
|
|
|
|
2020-05-14 13:46:38 -04:00
|
|
|
|
if (builtin_f_type->builtin_real_s16->code () == TYPE_CODE_ERROR)
|
2020-04-02 13:13:02 -06:00
|
|
|
|
builtin_f_type->builtin_complex_s32
|
|
|
|
|
= arch_type (gdbarch, TYPE_CODE_ERROR, 256, "complex*32");
|
|
|
|
|
else
|
|
|
|
|
builtin_f_type->builtin_complex_s32
|
|
|
|
|
= init_complex_type ("complex*32", builtin_f_type->builtin_real_s16);
|
* gdbtypes.h (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Replace global
variable declaration with compatibility macro.
(struct builtin_f_type): New data type.
(builtin_f_type): Add prototype.
* f-lang.c (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Remove variables.
(f_language_arch_info): Use builtin_f_type instead of variables.
(build_fortran_types): Build builtin_f_type structure instead of
setting global type variables.
(f_type_data): New variable.
(builtin_f_type): New function.
(_initialize_f_language): Do not call build_fortran_types. Do not
swap global type variables. Register f_type_data per-gdbarch data.
2007-06-16 20:09:07 +00:00
|
|
|
|
|
|
|
|
|
return builtin_f_type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct gdbarch_data *f_type_data;
|
|
|
|
|
|
|
|
|
|
const struct builtin_f_type *
|
|
|
|
|
builtin_f_type (struct gdbarch *gdbarch)
|
|
|
|
|
{
|
Add some more casts (1/2)
Note: I needed to split this patch in two, otherwise it's too big for
the mailing list.
This patch adds explicit casts to situations where a void pointer is
assigned to a pointer to the "real" type. Building in C++ mode requires
those assignments to use an explicit cast. This includes, for example:
- callback arguments (cleanups, comparison functions, ...)
- data attached to some object (objfile, program space, etc) in the form
of a void pointer
- "user data" passed to some function
This patch comes from the commit "(mostly) auto-generated patch to insert
casts needed for C++", taken from Pedro's C++ branch.
Only files built on x86 with --enable-targets=all are modified, so the
native files for other arches will need to be dealt with separately.
I built-tested this with --enable-targets=all and reg-tested. To my
surprise, a test case (selftest.exp) had to be adjusted.
Here's the ChangeLog entry. Again, this was relatively quick to make
despite the length, thanks to David Malcom's script, although I don't
believe it's very useful information in that particular case...
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_make_prologue_cache): Add cast(s).
(aarch64_make_stub_cache): Likewise.
(value_of_aarch64_user_reg): Likewise.
* ada-lang.c (ada_inferior_data_cleanup): Likewise.
(get_ada_inferior_data): Likewise.
(get_ada_pspace_data): Likewise.
(ada_pspace_data_cleanup): Likewise.
(ada_complete_symbol_matcher): Likewise.
(ada_exc_search_name_matches): Likewise.
* ada-tasks.c (get_ada_tasks_pspace_data): Likewise.
(get_ada_tasks_inferior_data): Likewise.
* addrmap.c (addrmap_mutable_foreach_worker): Likewise.
(splay_obstack_alloc): Likewise.
(splay_obstack_free): Likewise.
* alpha-linux-tdep.c (alpha_linux_supply_gregset): Likewise.
(alpha_linux_collect_gregset): Likewise.
(alpha_linux_supply_fpregset): Likewise.
(alpha_linux_collect_fpregset): Likewise.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_lds): Likewise.
(alpha_sts): Likewise.
(alpha_sigtramp_frame_unwind_cache): Likewise.
(alpha_heuristic_frame_unwind_cache): Likewise.
(alpha_supply_int_regs): Likewise.
(alpha_fill_int_regs): Likewise.
(alpha_supply_fp_regs): Likewise.
(alpha_fill_fp_regs): Likewise.
* alphanbsd-tdep.c (alphanbsd_supply_fpregset): Likewise.
(alphanbsd_aout_supply_gregset): Likewise.
(alphanbsd_supply_gregset): Likewise.
* amd64-linux-tdep.c (amd64_linux_init_abi): Likewise.
(amd64_x32_linux_init_abi): Likewise.
* amd64-nat.c (amd64_supply_native_gregset): Likewise.
(amd64_collect_native_gregset): Likewise.
* amd64-tdep.c (amd64_frame_cache): Likewise.
(amd64_sigtramp_frame_cache): Likewise.
(amd64_epilogue_frame_cache): Likewise.
(amd64_supply_fxsave): Likewise.
(amd64_supply_xsave): Likewise.
(amd64_collect_fxsave): Likewise.
(amd64_collect_xsave): Likewise.
* amd64-windows-tdep.c (amd64_windows_frame_cache): Likewise.
* amd64obsd-tdep.c (amd64obsd_trapframe_cache): Likewise.
* arm-linux-tdep.c (arm_linux_supply_gregset): Likewise.
(arm_linux_collect_gregset): Likewise.
(arm_linux_supply_nwfpe): Likewise.
(arm_linux_collect_nwfpe): Likewise.
(arm_linux_supply_vfp): Likewise.
(arm_linux_collect_vfp): Likewise.
* arm-tdep.c (arm_find_mapping_symbol): Likewise.
(arm_prologue_unwind_stop_reason): Likewise.
(arm_prologue_this_id): Likewise.
(arm_prologue_prev_register): Likewise.
(arm_exidx_data_free): Likewise.
(arm_find_exidx_entry): Likewise.
(arm_stub_this_id): Likewise.
(arm_m_exception_this_id): Likewise.
(arm_m_exception_prev_register): Likewise.
(arm_normal_frame_base): Likewise.
(gdb_print_insn_arm): Likewise.
(arm_objfile_data_free): Likewise.
(arm_record_special_symbol): Likewise.
(value_of_arm_user_reg): Likewise.
* armbsd-tdep.c (armbsd_supply_fpregset): Likewise.
(armbsd_supply_gregset): Likewise.
* auto-load.c (auto_load_pspace_data_cleanup): Likewise.
(get_auto_load_pspace_data): Likewise.
(hash_loaded_script_entry): Likewise.
(eq_loaded_script_entry): Likewise.
(clear_section_scripts): Likewise.
(collect_matching_scripts): Likewise.
* auxv.c (auxv_inferior_data_cleanup): Likewise.
(get_auxv_inferior_data): Likewise.
* avr-tdep.c (avr_frame_unwind_cache): Likewise.
* ax-general.c (do_free_agent_expr_cleanup): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
(target_bfd_xclose): Likewise.
(target_bfd_get_section_table): Likewise.
* bfin-tdep.c (bfin_frame_cache): Likewise.
* block.c (find_block_in_blockvector): Likewise.
(call_site_for_pc): Likewise.
(block_find_non_opaque_type_preferred): Likewise.
* break-catch-sig.c (signal_catchpoint_insert_location): Likewise.
(signal_catchpoint_remove_location): Likewise.
(signal_catchpoint_breakpoint_hit): Likewise.
(signal_catchpoint_print_one): Likewise.
(signal_catchpoint_print_mention): Likewise.
(signal_catchpoint_print_recreate): Likewise.
* break-catch-syscall.c (get_catch_syscall_inferior_data): Likewise.
* breakpoint.c (do_cleanup_counted_command_line): Likewise.
(bp_location_compare_addrs): Likewise.
(get_first_locp_gte_addr): Likewise.
(check_tracepoint_command): Likewise.
(do_map_commands_command): Likewise.
(get_breakpoint_objfile_data): Likewise.
(free_breakpoint_probes): Likewise.
(do_captured_breakpoint_query): Likewise.
(compare_breakpoints): Likewise.
(bp_location_compare): Likewise.
(bpstat_remove_breakpoint_callback): Likewise.
(do_delete_breakpoint_cleanup): Likewise.
* bsd-uthread.c (bsd_uthread_set_supply_uthread): Likewise.
(bsd_uthread_set_collect_uthread): Likewise.
(bsd_uthread_activate): Likewise.
(bsd_uthread_fetch_registers): Likewise.
(bsd_uthread_store_registers): Likewise.
* btrace.c (check_xml_btrace_version): Likewise.
(parse_xml_btrace_block): Likewise.
(parse_xml_btrace_pt_config_cpu): Likewise.
(parse_xml_btrace_pt_raw): Likewise.
(parse_xml_btrace_pt): Likewise.
(parse_xml_btrace_conf_bts): Likewise.
(parse_xml_btrace_conf_pt): Likewise.
(do_btrace_data_cleanup): Likewise.
* c-typeprint.c (find_typedef_for_canonicalize): Likewise.
* charset.c (cleanup_iconv): Likewise.
(do_cleanup_iterator): Likewise.
* cli-out.c (cli_uiout_dtor): Likewise.
(cli_table_begin): Likewise.
(cli_table_body): Likewise.
(cli_table_end): Likewise.
(cli_table_header): Likewise.
(cli_begin): Likewise.
(cli_end): Likewise.
(cli_field_int): Likewise.
(cli_field_skip): Likewise.
(cli_field_string): Likewise.
(cli_field_fmt): Likewise.
(cli_spaces): Likewise.
(cli_text): Likewise.
(cli_message): Likewise.
(cli_wrap_hint): Likewise.
(cli_flush): Likewise.
(cli_redirect): Likewise.
(out_field_fmt): Likewise.
(field_separator): Likewise.
(cli_out_set_stream): Likewise.
* cli/cli-cmds.c (compare_symtabs): Likewise.
* cli/cli-dump.c (call_dump_func): Likewise.
(restore_section_callback): Likewise.
* cli/cli-script.c (clear_hook_in_cleanup): Likewise.
(do_restore_user_call_depth): Likewise.
(do_free_command_lines_cleanup): Likewise.
* coff-pe-read.c (get_section_vmas): Likewise.
(pe_as16): Likewise.
(pe_as32): Likewise.
* coffread.c (coff_symfile_read): Likewise.
* common/agent.c (agent_look_up_symbols): Likewise.
* common/filestuff.c (do_close_cleanup): Likewise.
* common/format.c (free_format_pieces_cleanup): Likewise.
* common/vec.c (vec_o_reserve): Likewise.
* compile/compile-c-support.c (print_one_macro): Likewise.
* compile/compile-c-symbols.c (hash_symbol_error): Likewise.
(eq_symbol_error): Likewise.
(del_symbol_error): Likewise.
(error_symbol_once): Likewise.
(gcc_convert_symbol): Likewise.
(gcc_symbol_address): Likewise.
(hash_symname): Likewise.
(eq_symname): Likewise.
* compile/compile-c-types.c (hash_type_map_instance): Likewise.
(eq_type_map_instance): Likewise.
(insert_type): Likewise.
(convert_type): Likewise.
* compile/compile-object-load.c (munmap_listp_free_cleanup): Likewise.
(setup_sections): Likewise.
(link_hash_table_free): Likewise.
(copy_sections): Likewise.
* compile/compile-object-run.c (do_module_cleanup): Likewise.
* compile/compile.c (compile_print_value): Likewise.
(do_rmdir): Likewise.
(cleanup_compile_instance): Likewise.
(cleanup_unlink_file): Likewise.
* completer.c (free_completion_tracker): Likewise.
* corelow.c (add_to_spuid_list): Likewise.
* cp-namespace.c (reset_directive_searched): Likewise.
* cp-support.c (reset_directive_searched): Likewise.
* cris-tdep.c (cris_sigtramp_frame_unwind_cache): Likewise.
(cris_frame_unwind_cache): Likewise.
* d-lang.c (builtin_d_type): Likewise.
* d-namespace.c (reset_directive_searched): Likewise.
* dbxread.c (dbx_free_symfile_info): Likewise.
(do_free_bincl_list_cleanup): Likewise.
* disasm.c (hash_dis_line_entry): Likewise.
(eq_dis_line_entry): Likewise.
(dis_asm_print_address): Likewise.
(fprintf_disasm): Likewise.
(do_ui_file_delete): Likewise.
* doublest.c (convert_floatformat_to_doublest): Likewise.
* dummy-frame.c (pop_dummy_frame_bpt): Likewise.
(dummy_frame_prev_register): Likewise.
(dummy_frame_this_id): Likewise.
* dwarf2-frame-tailcall.c (cache_hash): Likewise.
(cache_eq): Likewise.
(cache_find): Likewise.
(tailcall_frame_this_id): Likewise.
(dwarf2_tailcall_prev_register_first): Likewise.
(tailcall_frame_prev_register): Likewise.
(tailcall_frame_dealloc_cache): Likewise.
(tailcall_frame_prev_arch): Likewise.
* dwarf2-frame.c (dwarf2_frame_state_free): Likewise.
(dwarf2_frame_set_init_reg): Likewise.
(dwarf2_frame_init_reg): Likewise.
(dwarf2_frame_set_signal_frame_p): Likewise.
(dwarf2_frame_signal_frame_p): Likewise.
(dwarf2_frame_set_adjust_regnum): Likewise.
(dwarf2_frame_adjust_regnum): Likewise.
(clear_pointer_cleanup): Likewise.
(dwarf2_frame_cache): Likewise.
(find_cie): Likewise.
(dwarf2_frame_find_fde): Likewise.
* dwarf2expr.c (dwarf_expr_address_type): Likewise.
(free_dwarf_expr_context_cleanup): Likewise.
* dwarf2loc.c (locexpr_find_frame_base_location): Likewise.
(locexpr_get_frame_base): Likewise.
(loclist_find_frame_base_location): Likewise.
(loclist_get_frame_base): Likewise.
(dwarf_expr_dwarf_call): Likewise.
(dwarf_expr_get_base_type): Likewise.
(dwarf_expr_push_dwarf_reg_entry_value): Likewise.
(dwarf_expr_get_obj_addr): Likewise.
(entry_data_value_coerce_ref): Likewise.
(entry_data_value_copy_closure): Likewise.
(entry_data_value_free_closure): Likewise.
(get_frame_address_in_block_wrapper): Likewise.
(dwarf2_evaluate_property): Likewise.
(dwarf2_compile_property_to_c): Likewise.
(needs_frame_read_addr_from_reg): Likewise.
(needs_frame_get_reg_value): Likewise.
(needs_frame_frame_base): Likewise.
(needs_frame_frame_cfa): Likewise.
(needs_frame_tls_address): Likewise.
(needs_frame_dwarf_call): Likewise.
(needs_dwarf_reg_entry_value): Likewise.
(get_ax_pc): Likewise.
(locexpr_read_variable): Likewise.
(locexpr_read_variable_at_entry): Likewise.
(locexpr_read_needs_frame): Likewise.
(locexpr_describe_location): Likewise.
(locexpr_tracepoint_var_ref): Likewise.
(locexpr_generate_c_location): Likewise.
(loclist_read_variable): Likewise.
(loclist_read_variable_at_entry): Likewise.
(loclist_describe_location): Likewise.
(loclist_tracepoint_var_ref): Likewise.
(loclist_generate_c_location): Likewise.
* dwarf2read.c (line_header_hash_voidp): Likewise.
(line_header_eq_voidp): Likewise.
(dwarf2_has_info): Likewise.
(dwarf2_get_section_info): Likewise.
(locate_dwz_sections): Likewise.
(hash_file_name_entry): Likewise.
(eq_file_name_entry): Likewise.
(delete_file_name_entry): Likewise.
(dw2_setup): Likewise.
(dw2_get_file_names_reader): Likewise.
(dw2_find_pc_sect_compunit_symtab): Likewise.
(hash_signatured_type): Likewise.
(eq_signatured_type): Likewise.
(add_signatured_type_cu_to_table): Likewise.
(create_debug_types_hash_table): Likewise.
(lookup_dwo_signatured_type): Likewise.
(lookup_dwp_signatured_type): Likewise.
(lookup_signatured_type): Likewise.
(hash_type_unit_group): Likewise.
(eq_type_unit_group): Likewise.
(get_type_unit_group): Likewise.
(process_psymtab_comp_unit_reader): Likewise.
(sort_tu_by_abbrev_offset): Likewise.
(process_skeletonless_type_unit): Likewise.
(psymtabs_addrmap_cleanup): Likewise.
(dwarf2_read_symtab): Likewise.
(psymtab_to_symtab_1): Likewise.
(die_hash): Likewise.
(die_eq): Likewise.
(load_full_comp_unit_reader): Likewise.
(reset_die_in_process): Likewise.
(free_cu_line_header): Likewise.
(handle_DW_AT_stmt_list): Likewise.
(hash_dwo_file): Likewise.
(eq_dwo_file): Likewise.
(hash_dwo_unit): Likewise.
(eq_dwo_unit): Likewise.
(create_dwo_cu_reader): Likewise.
(create_dwo_unit_in_dwp_v1): Likewise.
(create_dwo_unit_in_dwp_v2): Likewise.
(lookup_dwo_unit_in_dwp): Likewise.
(dwarf2_locate_dwo_sections): Likewise.
(dwarf2_locate_common_dwp_sections): Likewise.
(dwarf2_locate_v2_dwp_sections): Likewise.
(hash_dwp_loaded_cutus): Likewise.
(eq_dwp_loaded_cutus): Likewise.
(lookup_dwo_cutu): Likewise.
(abbrev_table_free_cleanup): Likewise.
(dwarf2_free_abbrev_table): Likewise.
(find_partial_die_in_comp_unit): Likewise.
(free_line_header_voidp): Likewise.
(follow_die_offset): Likewise.
(follow_die_sig_1): Likewise.
(free_heap_comp_unit): Likewise.
(free_stack_comp_unit): Likewise.
(dwarf2_free_objfile): Likewise.
(per_cu_offset_and_type_hash): Likewise.
(per_cu_offset_and_type_eq): Likewise.
(get_die_type_at_offset): Likewise.
(partial_die_hash): Likewise.
(partial_die_eq): Likewise.
(dwarf2_per_objfile_free): Likewise.
(hash_strtab_entry): Likewise.
(eq_strtab_entry): Likewise.
(add_string): Likewise.
(hash_symtab_entry): Likewise.
(eq_symtab_entry): Likewise.
(delete_symtab_entry): Likewise.
(cleanup_mapped_symtab): Likewise.
(add_indices_to_cpool): Likewise.
(hash_psymtab_cu_index): Likewise.
(eq_psymtab_cu_index): Likewise.
(add_address_entry_worker): Likewise.
(unlink_if_set): Likewise.
(write_one_signatured_type): Likewise.
(save_gdb_index_command): Likewise.
* elfread.c (elf_symtab_read): Likewise.
(elf_gnu_ifunc_cache_hash): Likewise.
(elf_gnu_ifunc_cache_eq): Likewise.
(elf_gnu_ifunc_record_cache): Likewise.
(elf_gnu_ifunc_resolve_by_cache): Likewise.
(elf_get_probes): Likewise.
(probe_key_free): Likewise.
* f-lang.c (builtin_f_type): Likewise.
* frame-base.c (frame_base_append_sniffer): Likewise.
(frame_base_set_default): Likewise.
(frame_base_find_by_frame): Likewise.
* frame-unwind.c (frame_unwind_prepend_unwinder): Likewise.
(frame_unwind_append_unwinder): Likewise.
(frame_unwind_find_by_frame): Likewise.
* frame.c (frame_addr_hash): Likewise.
(frame_addr_hash_eq): Likewise.
(frame_stash_find): Likewise.
(do_frame_register_read): Likewise.
(unwind_to_current_frame): Likewise.
(frame_cleanup_after_sniffer): Likewise.
* frv-linux-tdep.c (frv_linux_sigtramp_frame_cache): Likewise.
* frv-tdep.c (frv_frame_unwind_cache): Likewise.
* ft32-tdep.c (ft32_frame_cache): Likewise.
* gcore.c (do_bfd_delete_cleanup): Likewise.
(gcore_create_callback): Likewise.
* gdb_bfd.c (hash_bfd): Likewise.
(eq_bfd): Likewise.
(gdb_bfd_open): Likewise.
(free_one_bfd_section): Likewise.
(gdb_bfd_ref): Likewise.
(gdb_bfd_unref): Likewise.
(get_section_descriptor): Likewise.
(gdb_bfd_map_section): Likewise.
(gdb_bfd_crc): Likewise.
(gdb_bfd_mark_parent): Likewise.
(gdb_bfd_record_inclusion): Likewise.
(gdb_bfd_requires_relocations): Likewise.
(print_one_bfd): Likewise.
* gdbtypes.c (type_pair_hash): Likewise.
(type_pair_eq): Likewise.
(builtin_type): Likewise.
(objfile_type): Likewise.
* gnu-v3-abi.c (vtable_ptrdiff_type): Likewise.
(vtable_address_point_offset): Likewise.
(gnuv3_get_vtable): Likewise.
(hash_value_and_voffset): Likewise.
(eq_value_and_voffset): Likewise.
(compare_value_and_voffset): Likewise.
(compute_vtable_size): Likewise.
(gnuv3_get_typeid_type): Likewise.
* go-lang.c (builtin_go_type): Likewise.
* guile/scm-block.c (bkscm_hash_block_smob): Likewise.
(bkscm_eq_block_smob): Likewise.
(bkscm_objfile_block_map): Likewise.
(bkscm_del_objfile_blocks): Likewise.
* guile/scm-breakpoint.c (bpscm_build_bp_list): Likewise.
* guile/scm-disasm.c (gdbscm_disasm_read_memory_worker): Likewise.
(gdbscm_disasm_print_address): Likewise.
* guile/scm-frame.c (frscm_hash_frame_smob): Likewise.
(frscm_eq_frame_smob): Likewise.
(frscm_inferior_frame_map): Likewise.
(frscm_del_inferior_frames): Likewise.
* guile/scm-gsmob.c (gdbscm_add_objfile_ref): Likewise.
* guile/scm-objfile.c (ofscm_handle_objfile_deleted): Likewise.
(ofscm_objfile_smob_from_objfile): Likewise.
* guile/scm-ports.c (ioscm_write): Likewise.
(ioscm_file_port_delete): Likewise.
(ioscm_file_port_rewind): Likewise.
(ioscm_file_port_put): Likewise.
(ioscm_file_port_write): Likewise.
* guile/scm-progspace.c (psscm_handle_pspace_deleted): Likewise.
(psscm_pspace_smob_from_pspace): Likewise.
* guile/scm-safe-call.c (scscm_recording_pre_unwind_handler): Likewise.
(scscm_recording_unwind_handler): Likewise.
(gdbscm_with_catch): Likewise.
(scscm_call_0_body): Likewise.
(scscm_call_1_body): Likewise.
(scscm_call_2_body): Likewise.
(scscm_call_3_body): Likewise.
(scscm_call_4_body): Likewise.
(scscm_apply_1_body): Likewise.
(scscm_eval_scheme_string): Likewise.
(gdbscm_safe_eval_string): Likewise.
(scscm_source_scheme_script): Likewise.
(gdbscm_safe_source_script): Likewise.
* guile/scm-string.c (gdbscm_call_scm_to_stringn): Likewise.
(gdbscm_call_scm_from_stringn): Likewise.
* guile/scm-symbol.c (syscm_hash_symbol_smob): Likewise.
(syscm_eq_symbol_smob): Likewise.
(syscm_get_symbol_map): Likewise.
(syscm_del_objfile_symbols): Likewise.
* guile/scm-symtab.c (stscm_hash_symtab_smob): Likewise.
(stscm_eq_symtab_smob): Likewise.
(stscm_objfile_symtab_map): Likewise.
(stscm_del_objfile_symtabs): Likewise.
* guile/scm-type.c (tyscm_hash_type_smob): Likewise.
(tyscm_eq_type_smob): Likewise.
(tyscm_type_map): Likewise.
(tyscm_copy_type_recursive): Likewise.
(save_objfile_types): Likewise.
* guile/scm-utils.c (extract_arg): Likewise.
* h8300-tdep.c (h8300_frame_cache): Likewise.
* hppa-linux-tdep.c (hppa_linux_sigtramp_frame_unwind_cache): Likewise.
* hppa-tdep.c (compare_unwind_entries): Likewise.
(find_unwind_entry): Likewise.
(hppa_frame_cache): Likewise.
(hppa_stub_frame_unwind_cache): Likewise.
* hppanbsd-tdep.c (hppanbsd_supply_gregset): Likewise.
* hppaobsd-tdep.c (hppaobsd_supply_gregset): Likewise.
(hppaobsd_supply_fpregset): Likewise.
* i386-cygwin-tdep.c (core_process_module_section): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* i386-tdep.c (i386_frame_cache): Likewise.
(i386_epilogue_frame_cache): Likewise.
(i386_sigtramp_frame_cache): Likewise.
(i386_supply_gregset): Likewise.
(i386_collect_gregset): Likewise.
(i386_gdbarch_init): Likewise.
* i386obsd-tdep.c (i386obsd_aout_supply_regset): Likewise.
(i386obsd_trapframe_cache): Likewise.
* i387-tdep.c (i387_supply_fsave): Likewise.
(i387_collect_fsave): Likewise.
(i387_supply_fxsave): Likewise.
(i387_collect_fxsave): Likewise.
(i387_supply_xsave): Likewise.
(i387_collect_xsave): Likewise.
* ia64-tdep.c (ia64_frame_cache): Likewise.
(ia64_sigtramp_frame_cache): Likewise.
* infcmd.c (attach_command_continuation): Likewise.
(attach_command_continuation_free_args): Likewise.
* inferior.c (restore_inferior): Likewise.
(delete_thread_of_inferior): Likewise.
* inflow.c (inflow_inferior_data_cleanup): Likewise.
(get_inflow_inferior_data): Likewise.
(inflow_inferior_exit): Likewise.
* infrun.c (displaced_step_clear_cleanup): Likewise.
(restore_current_uiout_cleanup): Likewise.
(release_stop_context_cleanup): Likewise.
(do_restore_infcall_suspend_state_cleanup): Likewise.
(do_restore_infcall_control_state_cleanup): Likewise.
(restore_inferior_ptid): Likewise.
* inline-frame.c (block_starting_point_at): Likewise.
* iq2000-tdep.c (iq2000_frame_cache): Likewise.
* jit.c (get_jit_objfile_data): Likewise.
(get_jit_program_space_data): Likewise.
(jit_object_close_impl): Likewise.
(jit_find_objf_with_entry_addr): Likewise.
(jit_breakpoint_deleted): Likewise.
(jit_unwind_reg_set_impl): Likewise.
(jit_unwind_reg_get_impl): Likewise.
(jit_dealloc_cache): Likewise.
(jit_frame_sniffer): Likewise.
(jit_frame_prev_register): Likewise.
(jit_prepend_unwinder): Likewise.
(jit_inferior_exit_hook): Likewise.
(free_objfile_data): Likewise.
* jv-lang.c (jv_per_objfile_free): Likewise.
(get_dynamics_objfile): Likewise.
(get_java_class_symtab): Likewise.
(builtin_java_type): Likewise.
* language.c (language_string_char_type): Likewise.
(language_bool_type): Likewise.
(language_lookup_primitive_type): Likewise.
(language_lookup_primitive_type_as_symbol): Likewise.
* linespec.c (hash_address_entry): Likewise.
(eq_address_entry): Likewise.
(iterate_inline_only): Likewise.
(iterate_name_matcher): Likewise.
(decode_line_2_compare_items): Likewise.
(collect_one_symbol): Likewise.
(compare_symbols): Likewise.
(compare_msymbols): Likewise.
(add_symtabs_to_list): Likewise.
(collect_symbols): Likewise.
(compare_msyms): Likewise.
(add_minsym): Likewise.
(cleanup_linespec_result): Likewise.
* linux-fork.c (inferior_call_waitpid_cleanup): Likewise.
* linux-nat.c (delete_lwp_cleanup): Likewise.
(count_events_callback): Likewise.
(select_event_lwp_callback): Likewise.
(resume_stopped_resumed_lwps): Likewise.
* linux-tdep.c (get_linux_gdbarch_data): Likewise.
(invalidate_linux_cache_inf): Likewise.
(get_linux_inferior_data): Likewise.
(linux_find_memory_regions_thunk): Likewise.
(linux_make_mappings_callback): Likewise.
(linux_corefile_thread_callback): Likewise.
(find_mapping_size): Likewise.
* linux-thread-db.c (find_new_threads_callback): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m2-lang.c (builtin_m2_type): Likewise.
* m32c-tdep.c (m32c_analyze_frame_prologue): Likewise.
* m32r-linux-tdep.c (m32r_linux_sigtramp_frame_cache): Likewise.
(m32r_linux_supply_gregset): Likewise.
(m32r_linux_collect_gregset): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* m68k-tdep.c (m68k_frame_cache): Likewise.
* m68kbsd-tdep.c (m68kbsd_supply_fpregset): Likewise.
(m68kbsd_supply_gregset): Likewise.
* m68klinux-tdep.c (m68k_linux_sigtramp_frame_cache): Likewise.
* m88k-tdep.c (m88k_frame_cache): Likewise.
(m88k_supply_gregset): Likewise.
gdb/gdbserver/ChangeLog:
* dll.c (match_dll): Add cast(s).
(unloaded_dll): Likewise.
* linux-low.c (second_thread_of_pid_p): Likewise.
(delete_lwp_callback): Likewise.
(count_events_callback): Likewise.
(select_event_lwp_callback): Likewise.
(linux_set_resume_request): Likewise.
* server.c (accumulate_file_name_length): Likewise.
(emit_dll_description): Likewise.
(handle_qxfer_threads_worker): Likewise.
(visit_actioned_threads): Likewise.
* thread-db.c (any_thread_of): Likewise.
* tracepoint.c (same_process_p): Likewise.
(match_blocktype): Likewise.
(build_traceframe_info_xml): Likewise.
gdb/testsuite/ChangeLog:
* gdb.gdb/selftest.exp (do_steps_and_nexts): Adjust expected
source line.
2015-09-25 14:08:07 -04:00
|
|
|
|
return (const struct builtin_f_type *) gdbarch_data (gdbarch, f_type_data);
|
2003-02-27 18:13:37 +00:00
|
|
|
|
}
|
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
/* Command-list for the "set/show fortran" prefix command. */
|
|
|
|
|
static struct cmd_list_element *set_fortran_list;
|
|
|
|
|
static struct cmd_list_element *show_fortran_list;
|
|
|
|
|
|
2020-01-13 14:01:38 -05:00
|
|
|
|
void _initialize_f_language ();
|
2003-02-27 18:13:37 +00:00
|
|
|
|
void
|
2020-01-13 14:01:38 -05:00
|
|
|
|
_initialize_f_language ()
|
2003-02-27 18:13:37 +00:00
|
|
|
|
{
|
* gdbtypes.h (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Replace global
variable declaration with compatibility macro.
(struct builtin_f_type): New data type.
(builtin_f_type): Add prototype.
* f-lang.c (builtin_type_f_character, builtin_type_f_logical,
builtin_type_f_logical_s1, builtin_type_f_logical_s2,
builtin_type_f_integer, builtin_type_f_integer_s2, builtin_type_f_real,
builtin_type_f_real_s8, builtin_type_f_real_s16,
builtin_type_f_complex_s8, builtin_type_f_complex_s16,
builtin_type_f_complex_s32, builtin_type_f_void): Remove variables.
(f_language_arch_info): Use builtin_f_type instead of variables.
(build_fortran_types): Build builtin_f_type structure instead of
setting global type variables.
(f_type_data): New variable.
(builtin_f_type): New function.
(_initialize_f_language): Do not call build_fortran_types. Do not
swap global type variables. Register f_type_data per-gdbarch data.
2007-06-16 20:09:07 +00:00
|
|
|
|
f_type_data = gdbarch_data_register_post_init (build_fortran_types);
|
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 16:45:59 +01:00
|
|
|
|
|
|
|
|
|
add_basic_prefix_cmd ("fortran", no_class,
|
|
|
|
|
_("Prefix command for changing Fortran-specific settings."),
|
|
|
|
|
&set_fortran_list, "set fortran ", 0, &setlist);
|
|
|
|
|
|
|
|
|
|
add_show_prefix_cmd ("fortran", no_class,
|
|
|
|
|
_("Generic command for showing Fortran-specific settings."),
|
|
|
|
|
&show_fortran_list, "show fortran ", 0, &showlist);
|
|
|
|
|
|
|
|
|
|
add_setshow_boolean_cmd ("repack-array-slices", class_vars,
|
|
|
|
|
&repack_array_slices, _("\
|
|
|
|
|
Enable or disable repacking of non-contiguous array slices."), _("\
|
|
|
|
|
Show whether non-contiguous array slices are repacked."), _("\
|
|
|
|
|
When the user requests a slice of a Fortran array then we can either return\n\
|
|
|
|
|
a descriptor that describes the array in place (using the original array data\n\
|
|
|
|
|
in its existing location) or the original data can be repacked (copied) to a\n\
|
|
|
|
|
new location.\n\
|
|
|
|
|
\n\
|
|
|
|
|
When the content of the array slice is contiguous within the original array\n\
|
|
|
|
|
then the result will never be repacked, but when the data for the new array\n\
|
|
|
|
|
is non-contiguous within the original array repacking will only be performed\n\
|
|
|
|
|
when this setting is on."),
|
|
|
|
|
NULL,
|
|
|
|
|
show_repack_array_slices,
|
|
|
|
|
&set_fortran_list, &show_fortran_list);
|
|
|
|
|
|
|
|
|
|
/* Debug Fortran's array slicing logic. */
|
|
|
|
|
add_setshow_boolean_cmd ("fortran-array-slicing", class_maintenance,
|
|
|
|
|
&fortran_array_slicing_debug, _("\
|
|
|
|
|
Set debugging of Fortran array slicing."), _("\
|
|
|
|
|
Show debugging of Fortran array slicing."), _("\
|
|
|
|
|
When on, debugging of Fortran array slicing is enabled."),
|
|
|
|
|
NULL,
|
|
|
|
|
show_fortran_array_slicing_debug,
|
|
|
|
|
&setdebuglist, &showdebuglist);
|
1999-04-16 01:35:26 +00:00
|
|
|
|
}
|
Fortran function calls with arguments
Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.
It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.
This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.
Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.
Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.
Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.
gdb/testsuite/ChangeLog:
* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.
2019-03-06 08:23:00 +00:00
|
|
|
|
|
2020-11-13 11:03:05 +00:00
|
|
|
|
/* Ensures that function argument VALUE is in the appropriate form to
|
|
|
|
|
pass to a Fortran function. Returns a possibly new value that should
|
|
|
|
|
be used instead of VALUE.
|
|
|
|
|
|
|
|
|
|
When IS_ARTIFICIAL is true this indicates an artificial argument,
|
|
|
|
|
e.g. hidden string lengths which the GNU Fortran argument passing
|
|
|
|
|
convention specifies as being passed by value.
|
Fortran function calls with arguments
Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.
It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.
This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.
Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.
Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.
Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.
gdb/testsuite/ChangeLog:
* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.
2019-03-06 08:23:00 +00:00
|
|
|
|
|
2020-11-13 11:03:05 +00:00
|
|
|
|
When IS_ARTIFICIAL is false, the argument is passed by pointer. If the
|
|
|
|
|
value is already in target memory then return a value that is a pointer
|
|
|
|
|
to VALUE. If VALUE is not in memory (e.g. an integer literal), allocate
|
|
|
|
|
space in the target, copy VALUE in, and return a pointer to the in
|
|
|
|
|
memory copy. */
|
|
|
|
|
|
|
|
|
|
static struct value *
|
Fortran function calls with arguments
Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.
It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.
This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.
Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.
Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.
Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.
gdb/testsuite/ChangeLog:
* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.
2019-03-06 08:23:00 +00:00
|
|
|
|
fortran_argument_convert (struct value *value, bool is_artificial)
|
|
|
|
|
{
|
|
|
|
|
if (!is_artificial)
|
|
|
|
|
{
|
|
|
|
|
/* If the value is not in the inferior e.g. registers values,
|
|
|
|
|
convenience variables and user input. */
|
|
|
|
|
if (VALUE_LVAL (value) != lval_memory)
|
|
|
|
|
{
|
|
|
|
|
struct type *type = value_type (value);
|
|
|
|
|
const int length = TYPE_LENGTH (type);
|
|
|
|
|
const CORE_ADDR addr
|
|
|
|
|
= value_as_long (value_allocate_space_in_inferior (length));
|
|
|
|
|
write_memory (addr, value_contents (value), length);
|
|
|
|
|
struct value *val
|
|
|
|
|
= value_from_contents_and_address (type, value_contents (value),
|
|
|
|
|
addr);
|
|
|
|
|
return value_addr (val);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
return value_addr (value); /* Program variables, e.g. arrays. */
|
|
|
|
|
}
|
|
|
|
|
return value;
|
|
|
|
|
}
|
|
|
|
|
|
gdb/fortran: don't access non-existent type fields
When attempting to call a Fortran function for which there is no debug
information we currently trigger undefined behaviour in GDB by
accessing non-existent type fields.
The reason is that in order to prepare the arguments, for a call to a
Fortran function, we need to know the type of each argument. If the
function being called has no debug information then obviously GDB
doesn't know about the argument types and we should either give the
user an error or pick a suitable default. What we currently do is
just assume the field exist and access undefined memory, which is
clearly wrong.
The reason GDB needs to know the argument type is to tell if the
argument is artificial or not, artificial arguments will be passed by
value while non-artificial arguments will be passed by reference.
An ideal solution for this problem would be to allow the user to cast
the function to the correct type, we already do this to some degree
with the return value, for example:
(gdb) print some_func_ ()
'some_func_' has unknown return type; cast the call to its declared return type
(gdb) print (integer) some_func_ ()
$1 = 1
But if we could extend this to allow casting to the full function
type, GDB could figure out from the signature what are real
parameters, and what are artificial parameters. Maybe something like
this:
(gdb) print ((integer () (integer, double)) some_other_func_ (1, 2.3)
Alas, right now the Fortran expression parser doesn't seem to support
parsing function signatures, and we certainly don't have support for
figuring out real vs artificial arguments from a signature.
Still, I think we can prevent GDB from accessing undefined memory and
provide a reasonable default behaviour.
In this commit I:
- Only ask if the argument is artificial if the type of the argument
is actually known.
- Unknown arguments are assumed to be artificial and passed by
value (non-artificial arguments are pass by reference).
- If an artificial argument is prefixed with '&' by the user then we
treat the argument as pass-by-reference.
With these three changes we avoid undefined behaviour in GDB, and
allow the user, in most cases, to get a reasonably natural default
behaviour.
gdb/ChangeLog:
PR fortran/26155
* f-lang.c (fortran_argument_convert): Delete declaration.
(fortran_prepare_argument): New function.
(evaluate_subexp_f): Move logic to new function
fortran_prepare_argument.
gdb/testsuite/ChangeLog:
PR fortran/26155
* gdb.fortran/call-no-debug-func.f90: New file.
* gdb.fortran/call-no-debug-prog.f90: New file.
* gdb.fortran/call-no-debug.exp: New file.
2020-11-13 10:39:23 +00:00
|
|
|
|
/* Prepare (and return) an argument value ready for an inferior function
|
|
|
|
|
call to a Fortran function. EXP and POS are the expressions describing
|
|
|
|
|
the argument to prepare. ARG_NUM is the argument number being
|
|
|
|
|
prepared, with 0 being the first argument and so on. FUNC_TYPE is the
|
|
|
|
|
type of the function being called.
|
|
|
|
|
|
|
|
|
|
IS_INTERNAL_CALL_P is true if this is a call to a function of type
|
|
|
|
|
TYPE_CODE_INTERNAL_FUNCTION, otherwise this parameter is false.
|
|
|
|
|
|
|
|
|
|
NOSIDE has its usual meaning for expression parsing (see eval.c).
|
|
|
|
|
|
|
|
|
|
Arguments in Fortran are normally passed by address, we coerce the
|
|
|
|
|
arguments here rather than in value_arg_coerce as otherwise the call to
|
|
|
|
|
malloc (to place the non-lvalue parameters in target memory) is hit by
|
|
|
|
|
this Fortran specific logic. This results in malloc being called with a
|
|
|
|
|
pointer to an integer followed by an attempt to malloc the arguments to
|
|
|
|
|
malloc in target memory. Infinite recursion ensues. */
|
|
|
|
|
|
|
|
|
|
static value *
|
|
|
|
|
fortran_prepare_argument (struct expression *exp, int *pos,
|
|
|
|
|
int arg_num, bool is_internal_call_p,
|
|
|
|
|
struct type *func_type, enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
if (is_internal_call_p)
|
|
|
|
|
return evaluate_subexp_with_coercion (exp, pos, noside);
|
|
|
|
|
|
|
|
|
|
bool is_artificial = ((arg_num >= func_type->num_fields ())
|
|
|
|
|
? true
|
|
|
|
|
: TYPE_FIELD_ARTIFICIAL (func_type, arg_num));
|
|
|
|
|
|
|
|
|
|
/* If this is an artificial argument, then either, this is an argument
|
|
|
|
|
beyond the end of the known arguments, or possibly, there are no known
|
|
|
|
|
arguments (maybe missing debug info).
|
|
|
|
|
|
|
|
|
|
For these artificial arguments, if the user has prefixed it with '&'
|
|
|
|
|
(for address-of), then lets always allow this to succeed, even if the
|
|
|
|
|
argument is not actually in inferior memory. This will allow the user
|
|
|
|
|
to pass arguments to a Fortran function even when there's no debug
|
|
|
|
|
information.
|
|
|
|
|
|
|
|
|
|
As we already pass the address of non-artificial arguments, all we
|
|
|
|
|
need to do if skip the UNOP_ADDR operator in the expression and mark
|
|
|
|
|
the argument as non-artificial. */
|
|
|
|
|
if (is_artificial && exp->elts[*pos].opcode == UNOP_ADDR)
|
|
|
|
|
{
|
|
|
|
|
(*pos)++;
|
|
|
|
|
is_artificial = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct value *arg_val = evaluate_subexp_with_coercion (exp, pos, noside);
|
|
|
|
|
return fortran_argument_convert (arg_val, is_artificial);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 07:27:57 -07:00
|
|
|
|
/* Prepare (and return) an argument value ready for an inferior function
|
|
|
|
|
call to a Fortran function. EXP and POS are the expressions describing
|
|
|
|
|
the argument to prepare. ARG_NUM is the argument number being
|
|
|
|
|
prepared, with 0 being the first argument and so on. FUNC_TYPE is the
|
|
|
|
|
type of the function being called.
|
|
|
|
|
|
|
|
|
|
IS_INTERNAL_CALL_P is true if this is a call to a function of type
|
|
|
|
|
TYPE_CODE_INTERNAL_FUNCTION, otherwise this parameter is false.
|
|
|
|
|
|
|
|
|
|
NOSIDE has its usual meaning for expression parsing (see eval.c).
|
|
|
|
|
|
|
|
|
|
Arguments in Fortran are normally passed by address, we coerce the
|
|
|
|
|
arguments here rather than in value_arg_coerce as otherwise the call to
|
|
|
|
|
malloc (to place the non-lvalue parameters in target memory) is hit by
|
|
|
|
|
this Fortran specific logic. This results in malloc being called with a
|
|
|
|
|
pointer to an integer followed by an attempt to malloc the arguments to
|
|
|
|
|
malloc in target memory. Infinite recursion ensues. */
|
|
|
|
|
|
|
|
|
|
static value *
|
|
|
|
|
fortran_prepare_argument (struct expression *exp,
|
|
|
|
|
expr::operation *subexp,
|
|
|
|
|
int arg_num, bool is_internal_call_p,
|
|
|
|
|
struct type *func_type, enum noside noside)
|
|
|
|
|
{
|
|
|
|
|
if (is_internal_call_p)
|
|
|
|
|
return subexp->evaluate_with_coercion (exp, noside);
|
|
|
|
|
|
|
|
|
|
bool is_artificial = ((arg_num >= func_type->num_fields ())
|
|
|
|
|
? true
|
|
|
|
|
: TYPE_FIELD_ARTIFICIAL (func_type, arg_num));
|
|
|
|
|
|
|
|
|
|
/* If this is an artificial argument, then either, this is an argument
|
|
|
|
|
beyond the end of the known arguments, or possibly, there are no known
|
|
|
|
|
arguments (maybe missing debug info).
|
|
|
|
|
|
|
|
|
|
For these artificial arguments, if the user has prefixed it with '&'
|
|
|
|
|
(for address-of), then lets always allow this to succeed, even if the
|
|
|
|
|
argument is not actually in inferior memory. This will allow the user
|
|
|
|
|
to pass arguments to a Fortran function even when there's no debug
|
|
|
|
|
information.
|
|
|
|
|
|
|
|
|
|
As we already pass the address of non-artificial arguments, all we
|
|
|
|
|
need to do if skip the UNOP_ADDR operator in the expression and mark
|
|
|
|
|
the argument as non-artificial. */
|
|
|
|
|
if (is_artificial)
|
|
|
|
|
{
|
|
|
|
|
expr::unop_addr_operation *addrop
|
|
|
|
|
= dynamic_cast<expr::unop_addr_operation *> (subexp);
|
|
|
|
|
if (addrop != nullptr)
|
|
|
|
|
{
|
|
|
|
|
subexp = addrop->get_expression ().get ();
|
|
|
|
|
is_artificial = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct value *arg_val = subexp->evaluate_with_coercion (exp, noside);
|
|
|
|
|
return fortran_argument_convert (arg_val, is_artificial);
|
|
|
|
|
}
|
|
|
|
|
|
Fortran function calls with arguments
Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.
It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.
This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.
Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.
Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.
Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.
gdb/testsuite/ChangeLog:
* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.
2019-03-06 08:23:00 +00:00
|
|
|
|
/* See f-lang.h. */
|
|
|
|
|
|
|
|
|
|
struct type *
|
|
|
|
|
fortran_preserve_arg_pointer (struct value *arg, struct type *type)
|
|
|
|
|
{
|
2020-05-14 13:46:38 -04:00
|
|
|
|
if (value_type (arg)->code () == TYPE_CODE_PTR)
|
Fortran function calls with arguments
Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.
It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.
This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.
Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.
Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.
Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.
gdb/testsuite/ChangeLog:
* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.
2019-03-06 08:23:00 +00:00
|
|
|
|
return value_type (arg);
|
|
|
|
|
return type;
|
|
|
|
|
}
|
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 16:45:59 +01:00
|
|
|
|
|
|
|
|
|
/* See f-lang.h. */
|
|
|
|
|
|
|
|
|
|
CORE_ADDR
|
|
|
|
|
fortran_adjust_dynamic_array_base_address_hack (struct type *type,
|
|
|
|
|
CORE_ADDR address)
|
|
|
|
|
{
|
|
|
|
|
gdb_assert (type->code () == TYPE_CODE_ARRAY);
|
|
|
|
|
|
gdb: avoid resolving dynamic properties for non-allocated arrays
In PR gdb/27059 an issue was discovered where GDB would sometimes
trigger undefined behaviour in the form of signed integer overflow.
The problem here is that GDB was reading random garbage from the
inferior memory space, assuming this data was valid, and performing
arithmetic on it.
This bug raises an interesting general problem with GDB's DWARF
expression evaluator, which is this:
We currently assume that the DWARF expressions being evaluated are
well formed, and well behaving. As an example, this is the expression
that the bug was running into problems on, this was used as the
expression for a DW_AT_byte_stride of a DW_TAG_subrange_type:
DW_OP_push_object_address;
DW_OP_plus_uconst: 88;
DW_OP_deref;
DW_OP_push_object_address;
DW_OP_plus_uconst: 32;
DW_OP_deref;
DW_OP_mul
Two values are read from the inferior and multiplied together. GDB
should not assume that any value read from the inferior is in any way
sane, as such the implementation of DW_OP_mul should be guarding
against overflow and doing something semi-sane here.
However, it turns out that the original bug PR gdb/27059, is hitting a
more specific case, which doesn't require changes to the DWARF
expression evaluator, so I'm going to leave the above issue for
another day.
In the test mentioned in the bug GDB is actually trying to resolve the
dynamic type of a Fortran array that is NOT allocated. A
non-allocated Fortran array is one that does not have any data
allocated for it yet, and even the upper and lower bounds of the array
are not yet known.
It turns out that, at least for gfortran compiled code, the data
fields that describe the byte-stride are not initialised until the
array is allocated.
This leads me to the following conclusion: GDB should not try to
resolve the bounds, or stride information for an array that is not
allocated (or not associated, a similar, but slightly different
Fortran feature). Instead, each of these properties should be set to
undefined if the array is not allocated (or associated).
That is what this commit does. There's a new flag that is passed
around during the dynamic array resolution. When this flag is true
the dynamic properties are resolved using the DWARF expressions as
they currently are, but when this flag is false the expressions are
not evaluated, and instead the properties are set to undefined.
gdb/ChangeLog:
PR gdb/27059
* eval.c (evaluate_subexp_for_sizeof): Handle not allocated and
not associated arrays.
* f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't
adjust arrays that are not allocated/associated.
* gdbtypes.c (resolve_dynamic_range): Update header comment. Add
new parameter which is used to sometimes set dynamic properties to
undefined.
(resolve_dynamic_array_or_string): Update header comment. Add new
parameter which is used to guard evaluating dynamic properties.
Resolve allocated/associated properties first.
gdb/testsuite/ChangeLog:
PR gdb/27059
* gdb.dwarf2/dyn-type-unallocated.c: New file.
* gdb.dwarf2/dyn-type-unallocated.exp: New file.
2020-12-18 11:59:54 +00:00
|
|
|
|
/* We can't adjust the base address for arrays that have no content. */
|
|
|
|
|
if (type_not_allocated (type) || type_not_associated (type))
|
|
|
|
|
return address;
|
|
|
|
|
|
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 16:45:59 +01:00
|
|
|
|
int ndimensions = calc_f77_array_dims (type);
|
|
|
|
|
LONGEST total_offset = 0;
|
|
|
|
|
|
|
|
|
|
/* Walk through each of the dimensions of this array type and figure out
|
|
|
|
|
if any of the dimensions are "backwards", that is the base address
|
|
|
|
|
for this dimension points to the element at the highest memory
|
|
|
|
|
address and the stride is negative. */
|
|
|
|
|
struct type *tmp_type = type;
|
|
|
|
|
for (int i = 0 ; i < ndimensions; ++i)
|
|
|
|
|
{
|
|
|
|
|
/* Grab the range for this dimension and extract the lower and upper
|
|
|
|
|
bounds. */
|
|
|
|
|
tmp_type = check_typedef (tmp_type);
|
|
|
|
|
struct type *range_type = tmp_type->index_type ();
|
|
|
|
|
LONGEST lowerbound, upperbound, stride;
|
2020-12-09 13:51:57 -05: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 16:45:59 +01:00
|
|
|
|
error ("failed to get range bounds");
|
|
|
|
|
|
|
|
|
|
/* Figure out the stride for this dimension. */
|
|
|
|
|
struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (tmp_type));
|
|
|
|
|
stride = tmp_type->index_type ()->bounds ()->bit_stride ();
|
|
|
|
|
if (stride == 0)
|
|
|
|
|
stride = type_length_units (elt_type);
|
|
|
|
|
else
|
|
|
|
|
{
|
2021-01-28 10:12:10 -05:00
|
|
|
|
int unit_size
|
|
|
|
|
= gdbarch_addressable_memory_unit_size (elt_type->arch ());
|
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 16:45:59 +01:00
|
|
|
|
stride /= (unit_size * 8);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If this dimension is "backward" then figure out the offset
|
|
|
|
|
adjustment required to point to the element at the lowest memory
|
|
|
|
|
address, and add this to the total offset. */
|
|
|
|
|
LONGEST offset = 0;
|
|
|
|
|
if (stride < 0 && lowerbound < upperbound)
|
|
|
|
|
offset = (upperbound - lowerbound) * stride;
|
|
|
|
|
total_offset += offset;
|
|
|
|
|
tmp_type = TYPE_TARGET_TYPE (tmp_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Adjust the address of this object and return it. */
|
|
|
|
|
address += total_offset;
|
|
|
|
|
return address;
|
|
|
|
|
}
|