diff options
author | Tom Tromey <tromey@adacore.com> | 2024-02-29 09:46:11 -0700 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2024-03-18 08:22:37 -0600 |
commit | 1dd09e7f70d51eba4e2d9787959f07319c909110 (patch) | |
tree | f226e0067b0f81d4e2483c45daa03111108e0c4d /gdb/ada-lang.c | |
parent | 2b5f0fe3230f707ab736d759af4bf436d2c43837 (diff) | |
download | gdb-1dd09e7f70d51eba4e2d9787959f07319c909110.zip gdb-1dd09e7f70d51eba4e2d9787959f07319c909110.tar.gz gdb-1dd09e7f70d51eba4e2d9787959f07319c909110.tar.bz2 |
Fix Ada 'ptype' of access to array
ptype is a bit funny, in that it accepts both expressions and type
names. It also evaluates the resulting expression using
EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would
you expect ptype to possibly cause inferior execution?), but is also a
historical artifact of how expressions are implemented (there's no
EVAL_FOR_TYPE).
In Ada, calling a function with an array will sometimes result in a
"thick pointer" array descriptor being made. This is essentially a
structure holding a pointer and bounds information.
Currently, in such a callee, printing the type of the array will yield
funny results:
(gdb) print str.all
$1 = "Hello World"
(gdb) ptype str
type = array (<>) of character
(gdb) ptype str.all
type = array (1 .. 0) of character
That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch
trying to do "something" with an array descriptor, without doing too
much.
I tried briefly to make this code really dereference the array
descriptor and get the correct runtime type. However, that proved to
be tricky; it certainly can't be done for all access types, because
that will cause dynamic type resolution and end up printing just the
runtime type -- which with variants may be pretty far from what the
user may expect.
Instead, this patch arranges to just leave such types alone in this
situation. I don't think this should have an extra effects, because
things like array subscripting still work on thick pointers.
This patch also touches arrayptr.exp, because in that case the access
type is a "thin pointer", and this ensures that the output does not
change in that scenario.
Diffstat (limited to 'gdb/ada-lang.c')
-rw-r--r-- | gdb/ada-lang.c | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c index 1c26ebf..62fc668 100644 --- a/gdb/ada-lang.c +++ b/gdb/ada-lang.c @@ -10930,12 +10930,18 @@ ada_unop_ind_operation::evaluate (struct type *expect_type, if (noside == EVAL_AVOID_SIDE_EFFECTS) { if (ada_is_array_descriptor_type (type)) - /* GDB allows dereferencing GNAT array descriptors. */ { + /* GDB allows dereferencing GNAT array descriptors. + However, for 'ptype' we don't want to try to + "dereference" a thick pointer here -- that will end up + giving us an array with (1 .. 0) for bounds, which is + less clear than (<>). */ struct type *arrType = ada_type_of_array (arg1, 0); if (arrType == NULL) error (_("Attempt to dereference null array pointer.")); + if (is_thick_pntr (type)) + return arg1; return value_at_lazy (arrType, 0); } else if (type->code () == TYPE_CODE_PTR |