| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes the array type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the range type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_float_type and init_float_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_boolean_type and init_boolean_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_integer_type and init_integer_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes arch_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes a few spots to reuse the existing builting "void" type,
rather than construct a new one.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing
all uses with a call to value::lval.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch turns a grab bag of value functions to methods of value.
These are done together because their implementations are
interrelated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This turns the remaining value_contents functions -- value_contents,
value_contents_all, value_contents_for_printing, and
value_contents_for_printing_const -- into methods of value. It also
converts the static functions require_not_optimized_out and
require_available to be private methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This turns value_zero into a static "constructor" of value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes allocate_value to be a static "constructor" of value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the value_address and set_value_address functions to be
methods of value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This converts the value_lval_const and deprecated_lval_hack functions
to be methods on value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the value_lazy and set_value_lazy functions to be methods
of value. Much of this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes value_type to be a method of value. Much of this patch
was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
Remove the macro, replace all uses with calls to type::length.
Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
|
|
Remove the macro, replace all uses by calls to type::target_type.
Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
|
|
gdbarch implements its own registry-like approach. This patch changes
it to instead use registry.h. It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.
The main benefit of this change is that it introduces type safety to
the gdbarch registry. It also removes a bunch of code.
One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup. This
doesn't seem very important to me, though.
|
|
The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept
(some only with Fortran 2003) the optional parameter KIND. This
parameter determines the kind of the associated return value. So far,
implementation of this kind parameter has been missing in GDB.
Additionally, the one argument overload for the CMPLX intrinsic function
was not yet available.
This patch adds overloads for all above mentioned functions to the
Fortran intrinsics handling in GDB.
It re-writes the intrinsic function handling section to use the helper
methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic.
These methods define the action taken when a Fortran intrinsic function
is called with a certain amount of arguments (1/2/3). The helper methods
fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents
to the existing wrap and wrap2 methods.
After adding more overloads to the intrinsics handling, some of the
operation names were no longer accurate. E.g. UNOP_FORTRAN_CEILING
has been renamed to FORTRAN_CEILING as it is no longer a purely unary
intrinsic function. This patch also introduces intrinsic functions with
one, two, or three arguments to the Fortran parser and the
UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.
|
|
Currently, when asking GDB to print the type of a Fortran default type
such as INTEGER or REAL, GDB will return the default name of that type,
e.g. "integer"/"real":
(gdb) ptype integer
type = integer
(gdb) ptype real
type = real
For LOGICAL and COMPLEX it would return the actual underlying types
(gdb) ptype logical
type = logical*4
(gdb) ptype complex
type = complex*4
Similarly, GDB would print the default integer type for the underlying
default type:
(gdb) ptype integer*4
type = integer
(gdb) ptype real*4
type = real
(gdb) ptype logical
type = logical*4
(gdb) ptype complex*4
type = complex*4
This is inconsistent and a bit confusing. Both options somehow indicate
what the internal underlying type for the default type is - but I think
the logical/complex version is a bit clearer.
Consider again:
(gdb) ptype integer
type = integer
This indicates to a user that the type of "integer" is Fortran's default
integer type. Without examining "ptype integer*4" I would expect, that
any variable declared integer in the actual code would also fit into a
GDB integer. But, since we cannot adapt out internal types to the
compiler flags used at compile time of a debugged binary, this might be
wrong. Consider debugging Fortran code compiled with GNU and e.g. the
"-fdefault-integer-8" flag. In this case the gfortran default integer
would be integer*8 while GDB internally still would use a builtin_integer,
so an integer of the size of an integer*4 type. On the other hand having
GDB print
(gdb) ptype integer
type = integer*4
makes this clearer. I would still be tempted to fit a variable declared
integer in the code into a GDB integer - but at least ptype would
directly tell me what is going on. Note, that when debugging a binary
compiled with "-fdefault-integer-8" a user will always see the actual
underlying type of any variable declared "integer" in the Fortran code.
So having the code
program test
integer :: a = 5
print *, a ! breakpt
end program test
will, when breaking at breakpt print
(gdb) ptype var
type = integer(kind=4)
or
(gdb) ptype var
type = integer(kind=8)
depending on the compiler flag.
This patch changes the outputs for the REAL and INTEGER default types to
actually print the internally used type over the default type name.
The new behavior for the above examples is:
(gdb) ptype integer
type = integer*4
(gdb) ptype integer*4
type = integer*4
Existing testcases have been adapted to reflect the new behavior.
|
|
The currently implemented intrinsic type handling for Fortran missed some
tokens and their parsing. While still not all Fortran type kinds are
implemented this patch at least makes the currently handled types
consistent. As an example for what this patch does, consider the
intrinsic type INTEGER. GDB implemented the handling of the
keywords "integer" and "integer_2" but missed "integer_4" and "integer_8"
even though their corresponding internal types were already available as
the Fortran builtin types builtin_integer and builtin_integer_s8.
Similar problems applied to LOGICAL, REAL, and COMPLEX. This patch adds
all missing tokens and their parsing. Whenever a section containing the
type handling was touched, it also was reordered to be in a more easy to
grasp order. All INTEGER/REAL/LOGICAL/COMPLEX types were grouped
together and ordered ascending in their size making a missing one more
easy to spot.
Before this change GDB would print the following when tyring to use the
INTEGER keywords:
(gdb) set language fortran
(gdb) ptype integer*1
unsupported kind 1 for type integer
(gdb) ptype integer_1
No symbol table is loaded. Use the "file" command.
(gdb) ptype integer*2
type = integer*2
(gdb) ptype integer_2
type = integer*2
(gdb) ptype integer*4
type = integer
(gdb) ptype integer_4
No symbol table is loaded. Use the "file" command.
(gdb) ptype integer*8
type = integer*8
(gdb) ptype integer_8
No symbol table is loaded. Use the "file" command.
(gdb) ptype integer
type = integer
With this patch all keywords are available and the GDB prints:
(gdb) set language fortran
(gdb) ptype integer*1
type = integer*1
(gdb) ptype integer_1
type = integer*1
(gdb) ptype integer*2
type = integer*2
(gdb) ptype integer_2
type = integer*2
(gdb) ptype integer*4
type = integer*4
(gdb) ptype integer_4
type = integer*4
(gdb) ptype integer*8
type = integer*8
(gdb) ptype integer_8
type = integer*8
(gdb) ptype integer
type = integer
The described changes have been applied to INTEGER, REAL, COMPLEX,
and LOGICAL. Existing testcases have been adapted to reflect the
new behavior. Tests for formerly missing types have been added.
|
|
According to the Fortran standard, logical is of the size of a
'single numeric storage unit' (just like real and integer). For
gfortran, flang and ifx/ifort this storage unit (or the default
logical type) is of size kind 4, actually occupying 4 bytes of
storage, and so the default type for logical expressions in
Fortran should probably also be Logical*4 and not Logical*2. I
adapted GDB's behavior to be in line with
gfortran/ifort/ifx/flang.
|
|
Add a few newlines after the type definitions and remove some
unnecessary linebreaks.
|
|
Before this patch things like
(gdb) ptype complex*8
complex*16
(gdb) ptype complex*4
complex*8
were possible in GDB, which seems confusing for a user. The reason
is a mixup in the implementation of the Fortran COMPLEX type. In
Fortran the "*X" after a type would normally (I don't think this
is language required) specify the type's size in memory. For the
COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang)
specify not the size of the whole type but the size of the individual
two REALs used to form the COMPLEX. Thus, a COMPLEX*4 will usually
consist of two REAL*4s. Internally this type was represented by a
builtin_complex_s8 - but here I think the s8 actually meant the raw
size of the type. This is confusing and I renamed the types (e.g.
builting_complex_s8 became builtin_complex_s4 according to its most
common useage) and their printed names to their language equivalent.
Additionally, I added the default COMPLEX type "COMPLEX" being the same
as a COMPLEX*4 (as is normally the case) and removed the latter. I added
a few tests for this new behavior as well.
The new behavior is
(gdb) ptype complex*8
complex*8
(gdb) ptype complex*4
complex*4
|
|
|
|
Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.
|
|
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
|
|
Add `set print array-indexes' handling for Fortran arrays. Currently
the setting is ignored and indices are never shown.
Keep track of the most recent index handled so that any outstanding
repeated elements printed when the limit set by `set print elements' is
hit have the correct index shown.
Output now looks like:
(gdb) set print array-indexes on
(gdb) print array_1d
$1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1)
(gdb) set print repeats 4
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...)
(gdb)
for a 5-element vector and a 5 by 5 array filled with the value of 2.
|
|
Implement `set print repeats' handling for Fortran arrays. Currently
the setting is ignored and always treated as if no limit was set.
Unlike the generic array walker implemented decades ago the Fortran one
is a proper C++ class. Rather than trying to mimic the old walker then,
which turned out a bit of a challenge where interacting with the `set
print elements' setting, write it entirely from scratch, by adding an
extra specialization handler method for processing dimensions other than
the innermost one and letting the specialization class call the `walk_1'
method from the handler as it sees fit. This way repeats can be tracked
and the next inner dimension recursed into as a need arises only, or
unconditionally in the base class.
Keep track of the dimension number being handled in the class rather as
a parameter to the walker so that it does not have to be passed across
by the specialization class.
Use per-dimension element count tracking, needed to terminate processing
early when the limit set by `set print elements' is hit. This requires
extra care too where the limit triggers exactly where another element
that is a subarray begins. In that case rather than recursing we need
to terminate processing or lone `(...)' would be printed. Additionally
if the skipped element is the last one in the current dimension we need
to print `...' by hand, because `continue_walking' won't print it at the
upper level, because it can see the last element has already been taken
care of.
Preserve the existing semantics of `set print elements' where the total
count of the elements handled is matched against the trigger level which
is unlike with the C/C++ array printer where the per-dimension element
count is used instead.
Output now looks like:
(gdb) set print repeats 4
(gdb) print array_2d
$1 = ((2, <repeats 5 times>) <repeats 5 times>)
(gdb) set print elements 12
(gdb) print array_2d
$2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...)
(gdb)
for a 5 by 5 array filled with the value of 2.
Amend existing test cases accordingly that rely on the current incorrect
behavior and explicitly request that there be no limit for printing
repeated elements there.
Add suitable test cases as well covering sliced arrays in particular.
Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
There's a common pattern to call add_basic_prefix_cmd and
add_show_prefix_cmd to add matching set and show commands. Add the
add_setshow_prefix_cmd function to factor that out and use it at a few
places.
Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
|
|
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
|
|
Following on from the previous commit, this commit changes the API of
value_struct_elt to take gdb::optional<gdb::array_view<value *>>
instead of a pointer to the gdb::array_view.
This makes the optional nature of the array_view parameter explicit.
This commit is purely a refactoring commit, there should be no user
visible change after this commit.
I have deliberately kept this refactor separate from the previous two
commits as this is a more extensive change, and I'm not 100% sure that
using gdb::optional for the parameter type, instead of a pointer, is
going to be to everyone's taste. If there's push back on this patch
then this one can be dropped from the series.
gdb/ChangeLog:
* ada-lang.c (desc_bounds): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(desc_data): Likewise.
(desc_one_bound): Likewise.
* eval.c (structop_base_operation::evaluate_funcall): Pass
gdb::array_view, not a gdb::array_view* to value_struct_elt.
(eval_op_structop_struct): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(eval_op_structop_ptr): Likewise.
* f-lang.c (fortran_structop_operation::evaluate): Likewise.
* guile/scm-value.c (gdbscm_value_field): Likewise.
* m2-lang.c (eval_op_m2_high): Likewise.
(eval_op_m2_subscript): Likewise.
* opencl-lang.c (opencl_structop_operation::evaluate): Likewise.
* python/py-value.c (valpy_getitem): Likewise.
* rust-lang.c (rust_val_print_str): Likewise.
(rust_range): Likewise.
(rust_subscript): Likewise.
(eval_op_rust_structop): Likewise.
(rust_aggregate_operation::evaluate): Likewise.
* valarith.c (value_user_defined_op): Likewise.
* valops.c (search_struct_method): Change parameter type, update
function body accordingly, and update header comment.
(value_struct_elt): Change parameter type, update function body
accordingly.
* value.h (value_struct_elt): Update declaration.
|
|
Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
|
|
This commit replaces this patch:
https://sourceware.org/pipermail/gdb-patches/2021-January/174933.html
which was itself a replacement for this patch:
https://sourceware.org/pipermail/gdb-patches/2020-July/170335.html
The motivation behind the original patch can be seen in the new test,
which currently gives a GDB session like this:
(gdb) ptype var8
type = Type type6
PTR TO -> ( Type type2 :: ptr_1 )
PTR TO -> ( Type type2 :: ptr_2 )
End Type type6
(gdb) ptype var8%ptr_2
type = PTR TO -> ( Type type2
integer(kind=4) :: spacer
Type type1, allocatable :: t2_array(:) <------ Issue #1
End Type type2 )
(gdb) ptype var8%ptr_2%t2_array
Cannot access memory at address 0x38 <------ Issue #2
(gdb)
Issue #1: Here we see the abstract dynamic type, rather than the
resolved concrete type. Though in some cases the user might be
interested in the abstract dynamic type, I think that in most cases
showing the resolved concrete type will be of more use. Plus, the
user can always figure out the dynamic type (by source code inspection
if nothing else) given the concrete type, but it is much harder to
figure out the concrete type given only the dynamic type.
Issue #2: In this example, GDB evaluates the expression in
EVAL_AVOID_SIDE_EFFECTS mode (due to ptype). The value returned for
var8%ptr_2 will be a non-lazy, zero value of the correct dynamic
type. However, when GDB asks about the type of t2_array this requires
GDB to access the value of var8%ptr_2 in order to read the dynamic
properties. As this value was forced to zero (thanks to the use of
EVAL_AVOID_SIDE_EFFECTS) then GDB ends up accessing memory at a base
of zero plus some offset.
Both this patch, and my previous two attempts, have all tried to
resolve this problem by stopping EVAL_AVOID_SIDE_EFFECTS replacing the
result value with a zero value in some cases.
This new patch is influenced by how Ada handles its tagged typed.
There are plenty of examples in ada-lang.c, but one specific case is
ada_structop_operation::evaluate. When GDB spots that we are dealing
with a tagged (dynamic) type, and we're in EVAL_AVOID_SIDE_EFFECTS
mode, then GDB re-evaluates the child operation in EVAL_NORMAL mode.
This commit handles two cases like this specifically for Fortran, a
new fortran_structop_operation, and the already existing
fortran_undetermined, which is where we handle array accesses.
In these two locations we spot when we are dealing with a dynamic type
and re-evaluate the child operation in EVAL_NORMAL mode so that we
are able to access the dynamic properties of the type.
The rest of this commit message is my attempt to record why my
previous patches failed.
To understand my second patch, and why it failed lets consider two
expressions, this Fortran expression:
(gdb) ptype var8%ptr_2%t2_array --<A>
Operation: STRUCTOP_STRUCT --(1)
Operation: STRUCTOP_STRUCT --(2)
Operation: OP_VAR_VALUE --(3)
Symbol: var8
Block: 0x3980ac0
String: ptr_2
String: t2_array
And this C expression:
(gdb) ptype ptr && ptr->a == 3 --<B>
Operation: BINOP_LOGICAL_AND --(4)
Operation: OP_VAR_VALUE --(5)
Symbol: ptr
Block: 0x45a2a00
Operation: BINOP_EQUAL --(6)
Operation: STRUCTOP_PTR --(7)
Operation: OP_VAR_VALUE --(8)
Symbol: ptr
Block: 0x45a2a00
String: a
Operation: OP_LONG --(9)
Type: int
Constant: 0x0000000000000003
In expression <A> we should assume that t2_array is of dynamic type.
Nothing has dynamic type in expression <B>.
This is how GDB currently handles expression <A>, in all cases,
EVAL_AVOID_SIDE_EFFECTS or EVAL_NORMAL, an OP_VAR_VALUE operation
always returns the real value of the symbol, this is not forced to a
zero value even in EVAL_AVOID_SIDE_EFFECTS mode. This means that (3),
(5), and (8) will always return a real lazy value for the symbol.
However a STRUCTOP_STRUCT will always replace its result with a
non-lazy, zero value with the same type as its result. So (2) will
lookup the field ptr_2 and create a zero value with that type. In
this case the type is a pointer to a dynamic type.
Then, when we evaluate (1) to figure out the resolved type of
t2_array, we need to read the types dynamic properties. These
properties are stored in memory relative to the objects base address,
and the base address is in var8%ptr_2, which we already figured out
has the value zero. GDB then evaluates the DWARF expressions that
take the base address, add an offset and dereference. GDB then ends
up trying to access addresses like 0x16, 0x8, etc.
To fix this, I proposed changing STRUCTOP_STRUCT so that instead of
returning a zero value we instead returned the actual value
representing the structure's field in the target. My thinking was
that GDB would not try to access the value's contents unless it needed
it to resolve a dynamic type. This belief was incorrect.
Consider expression <B>. We already know that (5) and (8) will return
real values for the symbols being referenced. The BINOP_LOGICAL_AND,
operation (4) will evaluate both of its children in
EVAL_AVOID_SIDE_EFFECTS in order to get the types, this is required
for C++ operator lookup. This means that even if the value of (5)
would result in the BINOP_LOGICAL_AND returning false (say, ptr is
NULL), we still evaluate (6) in EVAL_AVOID_SIDE_EFFECTS mode.
Operation (6) will evaluate both children in EVAL_AVOID_SIDE_EFFECTS
mode, operation (9) is easy, it just returns a value with the constant
packed into it, but (7) is where the problem lies. Currently in GDB
this STRUCTOP_STRUCT will always return a non-lazy zero value of the
correct type.
When the results of (7) and (9) are back in the BINOP_LOGICAL_AND
operation (6), the two values are passed to value_equal which performs
the comparison and returns a result. Note, the two things compared
here are the immediate value (9), and a non-lazy zero value from (7).
However, with my proposed patch operation (7) no longer returns a zero
value, instead it returns a lazy value representing the actual value
in target memory. When we call value_equal in (6) this code causes
GDB to try and fetch the actual value from target memory. If `ptr` is
NULL then this will cause GDB to access some invalid address at an
offset from zero, this will most likely fail, and cause GDB to throw
an error instead of returning the expected type.
And so, we can now describe the problem that we're facing. The way
GDB's expression evaluator is currently written we assume, when in
EVAL_AVOID_SIDE_EFFECTS mode, that any value returned from a child
operation can safely have its content read without throwing an
error. If child operations start returning real values (instead of
the fake zero values), then this is simply not true.
If we wanted to work around this then we would need to rewrite almost
all operations (I would guess) so that EVAL_AVOID_SIDE_EFFECTS mode
does not cause evaluation of an operation to try and read the value of
a child operation. As an example, consider this current GDB code from
eval.c:
struct value *
eval_op_equal (struct type *expect_type, struct expression *exp,
enum noside noside, enum exp_opcode op,
struct value *arg1, struct value *arg2)
{
if (binop_user_defined_p (op, arg1, arg2))
{
return value_x_binop (arg1, arg2, op, OP_NULL, noside);
}
else
{
binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2);
int tem = value_equal (arg1, arg2);
struct type *type = language_bool_type (exp->language_defn,
exp->gdbarch);
return value_from_longest (type, (LONGEST) tem);
}
}
We could change this function to be this:
struct value *
eval_op_equal (struct type *expect_type, struct expression *exp,
enum noside noside, enum exp_opcode op,
struct value *arg1, struct value *arg2)
{
if (binop_user_defined_p (op, arg1, arg2))
{
return value_x_binop (arg1, arg2, op, OP_NULL, noside);
}
else
{
struct type *type = language_bool_type (exp->language_defn,
exp->gdbarch);
if (noside == EVAL_AVOID_SIDE_EFFECTS)
return value_zero (type, VALUE_LVAL (arg1));
else
{
binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2);
int tem = value_equal (arg1, arg2);
return value_from_longest (type, (LONGEST) tem);
}
}
}
Now we don't call value_equal unless we really need to. However, we
would need to make the same, or similar change to almost all
operations, which would be a big task, and might not be a direction we
wanted to take GDB in.
So, for now, I'm proposing we go with the more targeted, Fortran
specific solution, that does the minimal required in order to
correctly resolve the dynamic types.
gdb/ChangeLog:
* f-exp.h (class fortran_structop_operation): New class.
* f-exp.y (exp): Create fortran_structop_operation instead of the
generic structop_operation.
* f-lang.c (fortran_undetermined::evaluate): Re-evaluate
expression as EVAL_NORMAL if the result type was dynamic so we can
extract the actual array bounds.
(fortran_structop_operation::evaluate): New function.
gdb/testsuite/ChangeLog:
* gdb.fortran/dynamic-ptype-whatis.exp: New file.
* gdb.fortran/dynamic-ptype-whatis.f90: New file.
|
|
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.
|
|
EVAL_SKIP was needed in the old expression implementation due to its
linearized tree structure. This is not needed in the new
implementation, because it is trivial to not evaluate a subexpression.
This patch removes the last vestiges of EVAL_SKIP.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* value.h (eval_skip_value): Don't declare.
* opencl-lang.c (eval_opencl_assign): Update.
* m2-lang.c (eval_op_m2_high, eval_op_m2_subscript): Update.
* f-lang.c (eval_op_f_abs, eval_op_f_mod, eval_op_f_ceil)
(eval_op_f_floor, eval_op_f_modulo, eval_op_f_cmplx): Remove.
* expression.h (enum noside) <EVAL_SKIP>: Remove.
* expop.h (typeof_operation::evaluate)
(decltype_operation::evaluate, unop_addr_operation::evaluate)
(unop_sizeof_operation::evaluate, assign_operation::evaluate)
(cxx_cast_operation::evaluate): Update.
* eval.c (eval_skip_value): Remove.
(eval_op_scope, eval_op_var_entry_value)
(eval_op_func_static_var, eval_op_string, eval_op_objc_selector)
(eval_op_concat, eval_op_ternop, eval_op_structop_struct)
(eval_op_structop_ptr, eval_op_member, eval_op_add, eval_op_sub)
(eval_op_binary, eval_op_subscript, eval_op_equal)
(eval_op_notequal, eval_op_less, eval_op_gtr, eval_op_geq)
(eval_op_leq, eval_op_repeat, eval_op_plus, eval_op_neg)
(eval_op_complement, eval_op_lognot, eval_op_ind)
(eval_op_memval, eval_op_preinc, eval_op_predec)
(eval_op_postinc, eval_op_postdec, eval_op_type)
(eval_binop_assign_modify, eval_op_objc_msgcall)
(eval_multi_subscript, logical_and_operation::evaluate)
(logical_or_operation::evaluate, array_operation::evaluate)
(operation::evaluate_for_cast)
(var_msym_value_operation::evaluate_for_cast)
(var_value_operation::evaluate_for_cast): Update.
* c-lang.c (c_string_operation::evaluate): Update.
* c-exp.h (objc_nsstring_operation::evaluate)
(objc_selector_operation::evaluate): Update.
* ada-lang.c (ada_assign_operation::evaluate)
(eval_ternop_in_range, ada_unop_neg, ada_unop_in_range)
(ada_atr_size): Update.
|
|
This removes union exp_element functions that either create such
elements or walk them. struct expression no longer holds
exp_elements. A couple of language_defn methods are also removed, as
they are obsolete.
Note that this patch also removes the print_expression code. The only
in-tree caller of this was from dump_prefix_expression, which is only
called when expression debugging is enabled. Implementing this would
involve a fair amount of code, and it seems to me that prefix dumping
is preferable anyway, as it is unambiguous. So, I have not
reimplemented this feature.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* value.h (evaluate_subexp_with_coercion): Don't declare.
* parse.c (exp_descriptor_standard): Remove.
(expr_builder::expr_builder, expr_builder::release): Update.
(expression::expression): Remove size_t parameter.
(expression::~expression): Simplify.
(expression::resize): Remove.
(write_exp_elt, write_exp_elt_opcode, write_exp_elt_sym)
(write_exp_elt_msym, write_exp_elt_block, write_exp_elt_objfile)
(write_exp_elt_longcst, write_exp_elt_floatcst)
(write_exp_elt_type, write_exp_elt_intern, write_exp_string)
(write_exp_string_vector, write_exp_bitstring): Remove.
* p-lang.h (class pascal_language) <opcode_print_table,
op_print_tab>: Remove.
* p-lang.c (pascal_language::op_print_tab): Remove.
* opencl-lang.c (class opencl_language) <opcode_print_table>:
Remove.
* objc-lang.c (objc_op_print_tab): Remove.
(class objc_language) <opcode_print_table>: Remove.
* m2-lang.h (class m2_language) <opcode_print_table,
op_print_tab>: Remove.
* m2-lang.c (m2_language::op_print_tab): Remove.
* language.h (struct language_defn) <post_parser, expression_ops,
opcode_print_table>: Remove.
* language.c (language_defn::expression_ops)
(auto_or_unknown_language::opcode_print_table): Remove.
* go-lang.h (class go_language) <opcode_print_table,
op_print_tab>: Remove.
* go-lang.c (go_language::op_print_tab): Remove.
* f-lang.h (class f_language) <opcode_print_table>: Remove
<op_print_tab>: Remove.
* f-lang.c (f_language::op_print_tab): Remove.
* expression.h (union exp_element): Remove.
(struct expression): Remove size_t parameter from constructor.
<resize>: Remove.
<first_opcode>: Update.
<nelts, elts>: Remove.
(EXP_ELEM_TO_BYTES, BYTES_TO_EXP_ELEM): Remove.
(evaluate_subexp_standard, print_expression, op_string)
(dump_raw_expression): Don't declare.
* expprint.c (print_expression, print_subexp)
(print_subexp_funcall, print_subexp_standard, op_string)
(dump_raw_expression, dump_subexp, dump_subexp_body)
(dump_subexp_body_funcall, dump_subexp_body_standard): Remove.
(dump_prefix_expression): Update.
* eval.c (evaluate_subexp): Remove.
(evaluate_expression, evaluate_type): Update.
(evaluate_subexpression_type): Remove.
(fetch_subexp_value): Remove "pc" parameter. Update.
(extract_field_op, evaluate_struct_tuple, evaluate_funcall)
(evaluate_subexp_standard, evaluate_subexp_for_address)
(evaluate_subexp_with_coercion, evaluate_subexp_for_sizeof)
(evaluate_subexp_for_cast): Remove.
(parse_and_eval_type): Update.
* dtrace-probe.c (dtrace_probe::compile_to_ax): Update.
* d-lang.c (d_op_print_tab): Remove.
(class d_language) <opcode_print_table>: Remove.
* c-lang.h (c_op_print_tab): Don't declare.
* c-lang.c (c_op_print_tab): Remove.
(class c_language, class cplus_language, class asm_language, class
minimal_language) <opcode_print_table>: Remove.
* breakpoint.c (update_watchpoint, watchpoint_check)
(watchpoint_exp_is_const, watch_command_1): Update.
* ax-gdb.h (union exp_element): Don't declare.
* ax-gdb.c (const_var_ref, const_expr, maybe_const_expr)
(gen_repeat, gen_sizeof, gen_expr_for_cast, gen_expr)
(gen_expr_binop_rest): Remove.
(gen_trace_for_expr, gen_eval_for_expr, gen_printf): Update.
* ada-lang.c (ada_op_print_tab): Remove.
(class ada_language) <post_parser, opcode_print_table>: Remove.
|
|
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 implements several straightforward Fortran operations, primarily
by reusing existing template classes.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* f-lang.c (eval_op_f_abs, eval_op_f_mod, eval_op_f_ceil)
(eval_op_f_floor, eval_op_f_modulo, eval_op_f_cmplx)
(eval_op_f_kind): No longer static. Add "opcode" parameter.
(evaluate_subexp_f): Update.
* f-exp.h: New file.
|
|
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.
|
