LOC(X) returns the address of X as an integer:
https://gcc.gnu.org/onlinedocs/gfortran/LOC.html
Before:
(gdb) p LOC(r)
No symbol "LOC" in current context.
After:
(gdb) p LOC(r)
$1 = 0xffffdf48
gdb/ChangeLog:
2021-03-09 Felix Willgerodt <felix.willgerodt@intel.com>
* f-exp.h (eval_op_f_loc): Declare.
(expr::fortran_loc_operation): New typedef.
* f-exp.y (exp): Handle UNOP_FORTRAN_LOC after parsing an
UNOP_INTRINSIC.
(f77_keywords): Add LOC keyword.
* f-lang.c (eval_op_f_loc): New function.
* std-operator.def (UNOP_FORTRAN_LOC): New operator.
gdb/testsuite/ChangeLog:
2020-03-09 Felix Willgerodt <felix.willgerodt@intel.com>
* gdb.fortran/intrinsics.exp: Add LOC tests.
Add support for the SHAPE keyword to GDB's Fortran expression parser.
gdb/ChangeLog:
* f-exp.h (eval_op_f_array_shape): Declare.
(fortran_array_shape_operation): New type.
* f-exp.y (exp): Handle UNOP_FORTRAN_SHAPE after parsing
UNOP_INTRINSIC.
(f77_keywords): Add "shape" keyword.
* f-lang.c (fortran_array_shape): New function.
(eval_op_f_array_shape): New function.
* std-operator.def (UNOP_FORTRAN_SHAPE): New operator.
gdb/testsuite/ChangeLog:
* gdb.fortran/shape.exp: New file.
* gdb.fortran/shape.f90: New file.
Add support for the 'SIZE' keyword to the Fortran expression parser.
This returns the number of elements either in an entire array (passing
a single argument to SIZE), or in a particular dimension of an
array (passing two arguments to SIZE).
At this point I have not added support for the optional third argument
to SIZE, which controls the exact integer type of the result.
gdb/ChangeLog:
* f-exp.y (eval_op_f_array_size): Declare 1 and 2 argument forms
of this function.
(expr::fortran_array_size_1arg): New type.
(expr::fortran_array_size_2arg): Likewise.
* f-exp.y (exp): Handle FORTRAN_ARRAY_SIZE after parsing
UNOP_OR_BINOP_INTRINSIC.
(f77_keywords): Add "size" keyword.
* f-lang.c (fortran_array_size): New function.
(eval_op_f_array_size): New function, has a 1 arg and 2 arg form.
* std-operator.def (FORTRAN_ARRAY_SIZE): New operator.
gdb/testsuite/ChangeLog:
* gdb.fortran/size.exp: New file.
* gdb.fortran/size.f90: New file.
gfortran supports the RANK keyword, see:
https://gcc.gnu.org/onlinedocs/gfortran/RANK.html#RANK
this commit adds support for this keyword to GDB's Fortran expression
parser.
gdb/ChangeLog:
* f-exp.h (eval_op_f_rank): Declare.
(expr::fortran_rank_operation): New typedef.
* f-exp.y (exp): Handle UNOP_FORTRAN_RANK after parsing an
UNOP_INTRINSIC.
(f77_keywords): Add "rank" keyword.
* f-lang.c (eval_op_f_rank): New function.
* std-operator.def (UNOP_FORTRAN_RANK): New operator.
gdb/testsuite/ChangeLog:
* gdb.fortran/rank.exp: New file.
* gdb.fortran/rank.f90: New file.
Now that the Fortran parser has switched to the new style, there is no
need for the old Fortran evaluation code.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.h (class f_language) <expresssion_ops>: Remove.
<exp_descriptor_tab>: Remove.
* f-lang.c (fortran_value_subarray, evaluate_subexp_f)
(operator_length_f, print_unop_subexp_f, print_binop_subexp_f)
(print_subexp_f, dump_subexp_body_f, operator_check_f)
(f_language::exp_descriptor_tab, fortran_prepare_argument):
Remove.
This implements the Fortran ALLOCATED intrinsic.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-exp.h (eval_op_f_allocated): Declare.
(fortran_allocated_operation): New typedef.
* f-lang.c (eval_op_f_allocated): No longer static.
This implements the Fortran 1- and 2-argument "associated" operations.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_associated): New functions.
* f-exp.h (fortran_associated_1arg, fortran_associated_2arg): New
typedefs.
This adds class fortran_bound_1arg and fortran_bound_2arg, to
implement the Fortran lbound and ubound intrinsics.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (fortran_bound_1arg::evaluate)
(fortran_bound_2arg::evaluate): New methods.
* f-exp.h (class fortran_bound_1arg, class fortran_bound_2arg):
New.
This adds class fortran_undetermined, which implements
OP_F77_UNDETERMINED_ARGLIST. fortran_range_operation is also added
here, as it is needed by fortran_undetermined.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_addr_operation) <get_expression>: New
method.
* f-lang.c (fortran_undetermined::value_subarray)
(fortran_undetermined::evaluate): New methods.
(fortran_prepare_argument): New overload.
* f-exp.h (class fortran_range_operation)
(class fortran_undetermined): New classes.
This splits out a helper function, eval_op_f_allocated, that will be
used in a later patch.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_allocated): New function.
(evaluate_subexp_f): Use it.
This splits out a helper function, fortran_require_array, that will be
used in a later patch.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (fortran_require_array): New function.
(evaluate_subexp_f): Use it.
This splits UNOP_FORTRAN_KIND into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_kind): New function.
(evaluate_subexp_f): Use it.
This splits BINOP_FORTRAN_CMPLX into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_cmplx): New function.
(evaluate_subexp_f): Use it.
This splits BINOP_FORTRAN_MODULO into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_modulo): New function.
(evaluate_subexp_f): Use it.
This splits UNOP_FORTRAN_FLOOR into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_floor): New function.
(evaluate_subexp_f): Use it.
This splits UNOP_FORTRAN_CEILING into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_ceil): New function.
(evaluate_subexp_f): Use it.
This splits BINOP_MOD into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_mod): New function.
(evaluate_subexp_f): Use it.
This splits UNOP_ABS into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_abs): New function.
(evaluate_subexp_f): Use it.
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.
This commit adds support for the ASSOCIATED builtin to the Fortran
expression evaluator. The ASSOCIATED builtin takes one or two
arguments.
When passed a single pointer argument GDB returns a boolean indicating
if the pointer is associated with anything.
When passed two arguments the second argument should either be some a
pointer could point at or a second pointer.
If the second argument is a pointer target, then the result from
associated indicates if the pointer is pointing at this target.
If the second argument is another pointer, then the result from
associated indicates if the two pointers are pointing at the same
thing.
gdb/ChangeLog:
* f-exp.y (f77_keywords): Add 'associated'.
* f-lang.c (fortran_associated): New function.
(evaluate_subexp_f): Handle FORTRAN_ASSOCIATED.
(operator_length_f): Likewise.
(print_unop_or_binop_subexp_f): New function.
(print_subexp_f): Make use of print_unop_or_binop_subexp_f for
FORTRAN_ASSOCIATED, FORTRAN_LBOUND, and FORTRAN_UBOUND.
(dump_subexp_body_f): Handle FORTRAN_ASSOCIATED.
(operator_check_f): Likewise.
* std-operator.def: Add FORTRAN_ASSOCIATED.
gdb/testsuite/ChangeLog:
* gdb.fortran/associated.exp: New file.
* gdb.fortran/associated.f90: New file.
Add support for the LBOUND and UBOUND built in functions to the
Fortran expression parser.
Both support taking one or two arguments. A single argument, which
must be an array, returns an array containing all of the lower or
upper bound data.
When passed two arguments, the second argument is the dimension being
asked about. In this case the result is a scalar containing the lower
or upper bound just for that dimension.
Some examples of usage taken from the new test:
# Given:
# integer, dimension (-8:-1,-10:-2) :: neg_array
#
(gdb) p lbound (neg_array)
$1 = (-8, -10)
(gdb) p lbound (neg_array, 1)
$3 = -8
(gdb) p lbound (neg_array, 2)
$5 = -10
gdb/ChangeLog:
* f-exp.y (UNOP_OR_BINOP_INTRINSIC): New token.
(exp): New pattern using UNOP_OR_BINOP_INTRINSIC.
(one_or_two_args): New pattern.
(f77_keywords): Add lbound and ubound.
* f-lang.c (fortran_bounds_all_dims): New function.
(fortran_bounds_for_dimension): New function.
(evaluate_subexp_f): Handle FORTRAN_LBOUND and FORTRAN_UBOUND.
(operator_length_f): Likewise.
(print_subexp_f): Likewise.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* std-operator.def (FORTRAN_LBOUND): Define.
(FORTRAN_UBOUND): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/lbound-ubound.F90: New file.
* gdb.fortran/lbound-ubound.exp: New file.
Since this commit:
commit a5c641b57b
Date: Thu Oct 8 16:45:59 2020 +0100
gdb/fortran: Add support for Fortran array slices at the GDB prompt
A bug was introduced into GDB. Consider this Fortan array:
integer, dimension (1:10) :: array
array = 1
Now inside GDB:
(gdb) set $var = array
(gdb) set $var(1) = 2
Left operand of assignment is not an lvalue.
The problem is that the new code for slicing Fortran arrays now does
not set the lval type correctly for arrays that are not in memory.
This is easily fixed by making use of value_from_component.
After this the above example behaves as you'd expect.
gdb/ChangeLog:
* f-lang.c (fortran_value_subarray): Call value_from_component.
gdb/testsuite/ChangeLog:
* gdb.fortran/intvar-array.exp: New file.
* gdb.fortran/intvar-array.f90: New file.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
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.
I noticed hat evaluate_subexp_do_call takes an array of arguments and
a count -- but, unlike the usual convention, the count does not
include the first element.
This patch changes this function to match call_function_by_hand --
passing the callee separately, and using an array_view for the
arguments. This makes it simpler to understand.
Regression tested on x86-64 Fedora 28.
gdb/ChangeLog
2020-12-15 Tom Tromey <tom@tromey.com>
* f-lang.c (evaluate_subexp_f): Update.
* expression.h (evaluate_subexp_do_call): Update.
* eval.c (evaluate_subexp_do_call): Add callee parameter. Replace
nargs, argvec with array_view.
(evaluate_funcall): Update.
get_discrete_bounds currently has three possible return values (see its
current doc for details). It appears that for all callers, it would be
sufficient to have a boolean "worked" / "didn't work" return value.
Change the return type of get_discrete_bounds to bool and adjust all
callers. Doing so simplifies the following patch.
gdb/ChangeLog:
* gdbtypes.h (get_discrete_bounds): Return bool, adjust all
callers.
* gdbtypes.c (get_discrete_bounds): Return bool.
Change-Id: Ie51feee23c75f0cd7939742604282d745db59172
enum exp_opcode is created from all the .def files, but then each
language is required to implement its own op_name function to turn an
enum value to a string. This seemed over-complicated to me, and this
patch removes the per-language functions in favor of simply using the
.def names for all languages. Note that op_name is only used for
dumping expressions, which is a maintainer/debug feature.
Furthermore, I don't think there was any case where the .def name and
the string name differed.
gdb/ChangeLog
2020-11-30 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_op_name): Remove.
(exp_descriptor_rust): Update.
* parser-defs.h (op_name_standard): Don't declare.
(struct exp_descriptor) <op_name>: Remove.
* parse.c (exp_descriptor_standard): Update.
* opencl-lang.c (exp_descriptor_opencl): Update.
* m2-lang.c (m2_language::exp_descriptor_modula2): Update.
* f-lang.c (op_name_f): Remove.
(f_language::exp_descriptor_tab): Update.
* expression.h (op_name): Update.
* expprint.c (op_name): Rewrite.
(op_name_standard): Remove.
(dump_raw_expression, dump_subexp): Update.
* c-lang.c (exp_descriptor_c): Update.
* ax-gdb.c (gen_expr): Update.
* ada-lang.c (ada_op_name): Remove.
(ada_exp_descriptor): Update.
I get a bunch of these warnings when compiling for i386 (32-bit):
CXX f-lang.o
/home/simark/src/binutils-gdb/gdb/f-lang.c: In function 'value* fortran_value_subarray(value*, expression*, int*, int, noside)':
/home/simark/src/binutils-gdb/gdb/f-lang.c:453:48: error: format '%ld' expects argument of type 'long int', but argument 2 has type 'LONGEST' {aka 'long long int'} [-Werror=format=]
453 | debug_printf ("| | |-> Low bound: %ld\n", lb);
| ~~^ ~~
| | |
| | LONGEST {aka long long int}
| long int
| %lld
Fix them by using plongest/pulongest.
gdb/ChangeLog:
* f-lang.c (fortran_value_subarray): Use plongest/pulongest.
Change-Id: I666ead5593653d5a1a3dab2ffdc72942c928c7d2
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'.
One declaration in f-lang.h is for a function that doesn't even exist,
another is for a function that is only used within f-lang.c.
One declaration is deleted, the other function I make static in
f-lang.c.
gdb/ChangeLog:
* f-lang.c (fortran_argument_convert): Add declaration. Add
header comment, taken from f-lang.h. Make static.
* f-lang.h (f77_get_dynamic_array_length): Delete declaration.
(fortran_argument_convert): Delete declaration.
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 cad351d11d.
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.
In commit:
commit 6d81691950
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.
Moves the f_language class from f-lang.c into f-lang.h. The benefit
of this is that functions declared in other f-*.c files can become
member functions without having to go through a level of indirection.
Some additional support functions have now become private member
functions of the f_language class, these are mostly functions that
then called some other function that was itself a member of the
language_defn class hierarchy.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* f-exp.y (f_parse): Rename to...
(f_language::parser): ...this.
* f-lang.c (f_get_encoding): Rename to...
(f_language::get_encoding): ...this.
(f_op_print_tab): Rename to...
(f_language::op_print_tab): ...this.
(exp_descriptor_f): Rename to...
(f_language::exp_descriptor_tab): ...this.
(class f_language): Moved to f-lang.h.
(f_language::language_arch_info): New function, moved out of class
declaration.
(f_language::search_name_hash): Likewise.
(f_language::lookup_symbol_nonlocal): Likewise.
(f_language::get_symbol_name_matcher_inner): Likewise.
* f-lang.h: Add 'valprint.h' include.
(class f_language): Moved here from f-lang.c.
* f-typeprint.c (f_type_print_args): Delete commented out
declaration.
(f_print_typedef): Rename to...
(f_language::print_typedef): ...this.
(f_print_type): Rename to...
(f_language::print_type): ...this.
(f_type_print_varspec_prefix): Delete declaration and rename to...
(f_language::f_type_print_varspec_prefix): ...this.
(f_type_print_varspec_suffix): Delete declaration and rename to...
(f_language::f_type_print_varspec_suffix): ...this.
(f_type_print_base): Delete declaration and rename to...
(f_language::f_type_print_base): ...this.
* f-valprint.c (f_value_print_inner): Rename to...
(f_language::value_print_inner): ...this.
* parse.c: Delete 'f-lang.h' include.
GDB already has a global symbol `demangle` (a boolean), having a
language method called `demangle` is not a good idea as we often want
to reference `demangle` the control variable inside `demangle` the
member function.
This commit renames `demangle` the member function to
`demangle_symbol`.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language::demangle): Rename to...
(ada_language::demangle_symbol): ...this.
* c-lang.c (cplus_language::demangle): Rename to...
(cplus_language::demangle_symbol): ...this.
* d-lang.c (d_language::demangle): Rename to...
(d_language::demangle_symbol): ...this.
* f-lang.c (f_language::demangle): Rename to...
(f_language::demangle_symbol): ...this.
* go-lang.c (go_language::demangle): Rename to...
(go_language::demangle_symbol): ...this.
* language.c (language_demangle): Update call to demangle_symbol.
(auto_or_unknown_language::demangle): Rename to...
(auto_or_unknown_language::demangle_symbol): ...this.
* language.h (language_defn::demangle): Rename to...
(language_defn::demangle_symbol): ...this.
* objc-lang.c (objc_language::demangle): Rename to...
(objc_language::demangle_symbol): ...this.
* rust-lang.c (rust_language::demangle): Rename to...
(rust_language::demangle_symbol): ...this.
With this commit GDB now understands the syntax of Fortran array
strides, a user can type an expression including an array stride, but
they will only get an error informing them that array strides are not
supported.
This alone is an improvement on what we had before in GDB, better to
give the user a helpful message that a particular feature is not
supported than to just claim a syntax error.
Before:
(gdb) p array (1:10:2, 2:10:2)
A syntax error in expression, near `:2, 2:10:2)'.
Now:
(gdb) p array (1:10:2, 2:10:2)
Fortran array strides are not currently supported
Later commits will allow GDB to handle array strides correctly.
gdb/ChangeLog:
* expprint.c (dump_subexp_body_standard): Print RANGE_HAS_STRIDE.
* expression.h (enum range_type): Add RANGE_HAS_STRIDE.
* f-exp.y (arglist): Allow for a series of subranges.
(subrange): Add cases for subranges with strides.
* f-lang.c (value_f90_subarray): Catch use of array strides and
throw an error.
* parse.c (operator_length_standard): Handle RANGE_HAS_STRIDE.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices.exp: Add a new test.
To avoid confusion with other parts of GDB relating to types and
ranges, rename this enum to make it clearer that it is a set of
individual flags rather than an enumeration of different types of
range.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Change enum range_type to
range_flag and rename variables to match.
(dump_subexp_body_standard): Likewise.
* expression.h (enum range_type): Rename to...
(enum range_flag): ...this.
(range_types): Rename to...
(range_flags): ...this.
* f-lang.c (value_f90_subarray): Change enum range_type to
range_flag and rename variables to match.
* parse.c (operator_length_standard): Likewise.
* rust-exp.y (rust_parser::convert_ast_to_expression): Change enum
range_type to range_flag.
* rust-lang.c (rust_evaluate_funcall): Likewise.
(rust_range): Likewise.
(rust_compute_range): Likewise.
(rust_subscript): Likewise.
The expression range_type enum represents the following ideas:
- Lower bound is set to default,
- Upper bound is set to default,
- Upper bound is exclusive.
There are currently 6 entries in the enum to represent the combination
of all those ideas.
In a future commit I'd like to add stride information to the range,
this could in theory appear with any of the existing enum entries, so
this would take us to 12 enum entries.
This feels like its getting a little out of hand, so in this commit I
switch the range_type enum over to being a flags style enum. There's
one entry to represent no flags being set, then 3 flags to represent
the 3 ideas above. Adding stride information will require adding only
one more enum flag.
I've then gone through and updated the code to handle this change.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Update to reflect changes to
enum range_type.
(dump_subexp_body_standard): Likewise.
* expression.h (enum range_type): Convert to a bit field enum, and
make the enum unsigned.
* f-exp.y (subrange): Update to reflect changes to enum
range_type.
* f-lang.c (value_f90_subarray): Likewise.
* parse.c (operator_length_standard): Likewise.
* rust-exp.y (rust_parser::convert_ast_to_expression): Likewise.
* rust-lang.c (rust_range): Likewise.
(rust_compute_range): Likewise.
(rust_subscript): Likewise.
The Fortran specific OP_F77_UNDETERMINED_ARGLIST is currently handled
in the generic expression handling code. There's no reason why this
should be the case, so this commit moves handling of this into Fortran
specific files.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* eval.c: Remove 'f-lang.h' include.
(value_f90_subarray): Moved to f-lang.c.
(eval_call): Renamed to...
(evaluate_subexp_do_call): ...this, is no longer static, header
comment moved into header file.
(evaluate_funcall): Update call to eval_call.
(skip_undetermined_arglist): Moved to f-lang.c.
(fortran_value_subarray): Likewise.
(evaluate_subexp_standard): OP_F77_UNDETERMINED_ARGLIST handling
moved to evaluate_subexp_f.
(calc_f77_array_dims): Moved to f-lang.c
* expprint.c (print_subexp_funcall): New function.
(print_subexp_standard): OP_F77_UNDETERMINED_ARGLIST handling
moved to print_subexp_f, OP_FUNCALL uses new function.
(dump_subexp_body_funcall): New function.
(dump_subexp_body_standard): OP_F77_UNDETERMINED_ARGLIST handling
moved to dump_subexp_f, OP_FUNCALL uses new function.
* expression.h (evaluate_subexp_do_call): Declare.
* f-lang.c (value_f90_subarray): Moved from eval.c.
(skip_undetermined_arglist): Likewise.
(calc_f77_array_dims): Likewise.
(fortran_value_subarray): Likewise.
(evaluate_subexp_f): Add OP_F77_UNDETERMINED_ARGLIST support.
(operator_length_f): Likewise.
(print_subexp_f): Likewise.
(dump_subexp_body_f): Likewise.
* fortran-operator.def (OP_F77_UNDETERMINED_ARGLIST): Move
declaration of this operation to here.
* parse.c (operator_length_standard): OP_F77_UNDETERMINED_ARGLIST
support moved to operator_length_f.
* parser-defs.h (dump_subexp_body_funcall): Declare.
(print_subexp_funcall): Declare.
* std-operator.def (OP_F77_UNDETERMINED_ARGLIST): Moved to
fortran-operator.def.
The language_data type, from which language_defn inherits, is now
empty, and this commit removes it.
Each language is updated to no longer create and use a language_data
struct.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Delete.
(ada_language): Remove references to ada_language_data.
* c-lang.c (c_language_data): Delete.
(c_language): Remove references to c_language_data.
(cplus_language_data): Delete.
(cplus_language): Remove references to cplus_language_data.
(asm_language_data): Delete.
(asm_language): Remove references to asm_language_data.
(minimal_language_data): Delete.
(minimal_language): Remove references to minimal_language_data.
* d-lang.c (d_language_data): Delete.
(d_language): Remove references to d_language_data.
* f-lang.c (f_language_data): Delete.
(f_language): Remove references to f_language_data.
* go-lang.c (go_language_data): Delete.
(go_language): Remove references to go_language_data.
* language.c (unknown_language_data): Delete.
(unknown_language): Remove references to unknown_language_data.
(auto_language_data): Delete.
(auto_language): Remove references to auto_language_data.
* language.h (language_data): Delete struct.
(language_defn): No longer inherit from language_data.
* m2-lang.c (m2_language_data): Delete.
(m2_language): Remove references to m2_language_data.
* objc-lang.c (objc_language_data): Delete.
(objc_language): Remove references to objc_language_data.
* opencl-lang.c (opencl_language_data): Delete.
(opencl_language): Remove references to opencl_language_data.
* p-lang.c (pascal_language_data): Delete.
(pascal_language): Remove references to pascal_language_data.
* rust-lang.c (rust_language_data): Delete.
(rust_language): Remove references to rust_language_data.
Convert language_data::la_op_print_tab member variable to a virtual
method language_defn::opcode_print_table. I changed the name in order
to make it clearer (I hope) what the method does.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_op_print_tab
initializer.
(ada_language::opcode_print_table): New member function.
* c-lang.c (c_language_data): Remove la_op_print_tab initializer.
(c_language::opcode_print_table): New member function.
(cplus_language_data): Remove la_op_print_tab initializer.
(cplus_language::opcode_print_table): New member function.
(asm_language_data): Remove la_op_print_tab initializer.
(asm_language::opcode_print_table): New member function.
(minimal_language_data): Remove la_op_print_tab initializer.
(minimal_language::opcode_print_table): New member function.
* d-lang.c (d_language_data): Remove la_op_print_tab initializer.
(d_language::opcode_print_table): New member function.
* expprint.c (print_subexp_standard): Update call to
opcode_print_table.
(op_string): Likewise.
* f-lang.c (f_language_data): Remove la_op_print_tab initializer.
(f_language::opcode_print_table): New member function.
* go-lang.c (go_language_data): Remove la_op_print_tab
initializer.
(go_language::opcode_print_table): New member function.
* language.c (unknown_language_data): Remove la_op_print_tab
initializer.
(unknown_language::opcode_print_table): New member function.
(auto_language_data): Remove la_op_print_tab initializer.
(auto_language::opcode_print_table): New member function.
* language.h (language_data): Remove la_op_print_tab field.
(language_defn::opcode_print_table): Declare new member function.
* m2-lang.c (m2_language_data): Remove la_op_print_tab
initializer.
(m2_language::opcode_print_table): New member function.
* objc-lang.c (objc_language_data): Remove la_op_print_tab
initializer.
(objc_language::opcode_print_table): New member function.
* opencl-lang.c (opencl_language_data): Remove la_op_print_tab
initializer.
(opencl_language::opcode_print_table): New member function.
* p-lang.c (pascal_language_data): Remove la_op_print_tab
initializer.
(pascal_language::opcode_print_table): New member function.
* rust-lang.c (rust_language_data): Remove la_op_print_tab
initializer.
(rust_language::opcode_print_table): New member function.
Convert language_data::la_exp_desc member variable to a virtual
method language_defn::expression_ops. The change of names brings this
method more into line with the existing varobj_ops method, that also
returns a table of function pointers.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_exp_desc initializer.
(ada_language::expression_ops): New member function.
* c-lang.c (c_language_data): Remove la_exp_desc initializer.
(c_language::expression_ops): New member function.
(cplus_language_data): Remove la_exp_desc initializer.
(cplus_language::expression_ops): New member function.
(asm_language_data): Remove la_exp_desc initializer.
(asm_language::expression_ops): New member function.
(minimal_language_data): Remove la_exp_desc initializer.
(minimal_language::expression_ops): New member function.
* d-lang.c (d_language_data): Remove la_exp_desc initializer.
(d_language::expression_ops): New member function.
* eval.c (evaluate_subexp): Update call to expression_ops.
* expprint.c (print_subexp): Likewise.
(op_name): Likewise.
(dump_subexp_body): Likewise.
* f-lang.c (f_language_data): Remove la_exp_desc initializer.
(f_language::expression_ops): New member function.
* go-lang.c (go_language_data): Remove la_exp_desc initializer.
(go_language::expression_ops): New member function.
* language.c (language_defn::expression_ops): New function.
(unknown_language_data): Remove la_exp_desc initializer.
(auto_language_data): Likewise.
* language.h (language_data): Remove la_exp_desc field.
(language_defn::expression_ops): Declare new member function.
* m2-lang.c (m2_language_data): Remove la_exp_desc initializer.
(m2_language::expression_ops): New member function.
* objc-lang.c (objc_language_data): Remove la_exp_desc
initializer.
* opencl-lang.c (opencl_language_data): Remove la_exp_desc
initializer.
(opencl_language::expression_ops): New member function.
* p-lang.c (pascal_language_data): Remove la_exp_desc initializer.
* parse.c (operator_length): Update call to expression_ops.
(exp_iterate): Likewise.
* rust-lang.c (rust_language_data): Remove la_exp_desc
initializer.
(ruse_language::expression_ops): New member function.
Convert language_data::la_macro_expansion member variable to a virtual
method language_defn::macro_expansion.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_macro_expansion
initializer.
* c-lang.c (c_language_data): Likewise.
(c_language::macro_expansion): New member function.
(cplus_language_data): Likewise.
(cplus_language::macro_expansion): New member function.
(asm_language_data): Likewise.
(asm_language::macro_expansion): New member function.
(minimal_language_data): Likewise.
(minimal_language::macro_expansion): New member function.
* d-lang.c (d_language_data): Remove la_macro_expansion
initializer.
* f-lang.c (f_language_data): Likewise.
* go-lang.c (go_language_data): Likewise.
* language.c (unknown_language_data): Likewise.
(auto_language_data): Likewise.
* language.h (language_data): Remove la_macro_expansion field.
(language_defn::macro_expansion): New member function.
* m2-lang.c (m2_language_data): Remove la_macro_expansion
initializer.
* objc-lang.c (objc_language_data): Likewise.
(objc_language::macro_expansion): New member function.
* opencl-lang.c (opencl_language_data): Likewise.
(opencl_language::macro_expansion): New member function.
* p-lang.c (pascal_language_data): Remove la_macro_expansion
initializer.
* rust-lang.c (rust_language_data): Likewise.
* symtab.c (default_collect_symbol_completion_matches_break_on):
Update call to macro_expansion.
