In commit ed8fd0a342 ("[gdb/exp] Fix cast handling for indirection"), I
introduced the behaviour that even though we have:
...
(gdb) p *a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
we get:
...
(gdb) p (char)*a_loc ()
$1 = 97 'a'
...
In other words, the unknown return type of a_loc is inferred from the cast,
effectually evaluating:
...
(gdb) p (char)*(char *)a_loc ()
...
This is convient for the case that errno is defined as:
...
#define errno (*__errno_location ())
...
and the return type of __errno_location is unknown but the macro definition is
known, such that we can use:
...
(gdb) p (int)errno
...
instead of
...
(gdb) p *(int *)__errno_location ()
...
However, as Pedro has pointed out in post-commit review [1], this makes it
harder to reason about the semantics of an expression.
For instance, this:
...
(gdb) p (long long)*a_loc ()"
...
would be evaluated without debug info as:
...
(gdb) p (long long)*(long long *)a_loc ()"
...
but with debug info as:
...
(gdb) p (long long)*(char *)a_loc ()"
...
Fix this by instead simply erroring out for this case:
...
(gdb) p (char)*a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
Tested on x86_64-linux.
Approved-By: Pedro Alves <pedro@palves.net>
[1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
Consider a test-case compiled without debug info, containing:
...
char a = 'a';
char *
a_loc (void)
{
return &a;
}
...
We get:
...
(gdb) p (char)*a_loc ()
Cannot access memory at address 0x10
...
There's a bug in unop_ind_base_operation::evaluate that evaluates
"(char)*a_loc ()" the same as:
...
(gdb) p (char)*(char)a_loc ()
Cannot access memory at address 0x10
...
Fix this by instead evaluating it the same as:
...
(gdb) p (char)*(char *)a_loc ()
$1 = 97 'a'
...
Tested on x86_64-linux.
PR exp/31693
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
eval_op_ternop is only used by the implementation of
ternop_slice_operation. While working on another series, it was
convenient for me to merge this function into its only caller.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
While working on another patch I did this:
(gdb) set debug expression 1
(gdb) set language rust
(gdb) p "foo"
Operation: OP_AGGREGATE
Type: &str
Fatal signal: Segmentation fault
... etc ...
The problem is that the second field of the rust_aggregate_operation
is created as a nullptr, this can be seen in rust-parse.c. in the
function rust_parser::parse_string().
However, in expop.h, in the function dump_for_expression, we make the
assumption that the expressions will never be nullptr.
I did consider moving the nullptr handling into a new function
rust_aggregate_operation::dump, however, as the expression debug
dumping code is not exercised as much as it might be, I would rather
that this code be hardened and able to handle a nullptr without
crashing, so I propose that we add nullptr handling into the general
dump_for_expression function. The behaviour is now:
(gdb) set debug expression 1
(gdb) set language rust
(gdb) p "foo"
Operation: OP_AGGREGATE
Type: &str
nullptr
Vector:
String: data_ptr
Operation: UNOP_ADDR
Operation: OP_STRING
String: foo
String: length
Operation: OP_LONG
Type: usize
Constant: 3
evaluation of this expression requires the target program to be active
(gdb)
There's a new test to check for this case.
Reviewed-By: Tom Tromey <tom@tromey.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>
expop.h needs block.h for a single inline function. However, I don't
think most of the check_objfile functions need to be defined in the
header (just the templates). This patch moves the one offending
function and removes the include.
This helps resolve some cyclic include problem later in the series.
The only language-related thing frame.h needs is enum language, and that
is in defs.h.
Doing so reveals that a bunch of files were relying on frame.h to
include language.h, so fix the fallouts here and there.
Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
Reviewed-By: Bruno Larsen <blarsen@redhat.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.
This updates the Ada expression parser to implement context-sensitive
field name completion. This is PR ada/28727.
This is somewhat complicated due to some choices in the Ada lexer --
it chooses to represent a sequence of "."-separated identifiers as a
single token, so the parser must partially recreate the completer's
logic to find the completion word boundaries.
Despite the minor warts in this patch, though, it is a decent
improvement. It's possible that the DWARF reader rewrite will help
fix the package completion problem pointed out in this patch as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28727
This refactors the gdb expression completion code to make it easier to
add more types of completers.
In the old approach, just two kinds of completers were supported:
field names for some sub-expression, or tag names (like "enum
something"). The data for each kind was combined in single structure,
"expr_completion_state", and handled explicitly by
complete_expression.
In the new approach, the parser state just holds an object that is
responsible for implementing completion. This way, new completion
types can be added by subclassing this base object.
The structop completer is moved into structop_base_operation, and new
objects are defined for use by the completion code. This moves much
of the logic of expression completion out of completer.c as well.
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.
On x86 machines with xmm register, and with recent versions of
systemtap (and gcc?), it can occur that stap probe arguments will be
placed into xmm registers.
I notice this happening on a current Fedora Rawhide install with the
following package versions installed:
$ rpm -q glibc systemtap gcc
glibc-2.35.9000-10.fc37.x86_64
systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64
gcc-12.0.1-0.12.fc37.x86_64
If I check the probe data in libc, I see this:
$ readelf -n /lib64/libc.so.6
...
stapsdt 0x0000004d NT_STAPSDT (SystemTap probe descriptors)
Provider: libc
Name: pthread_start
Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx)
stapsdt 0x00000050 NT_STAPSDT (SystemTap probe descriptors)
Provider: libc
Name: pthread_create
Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp)
...
Notice that for both of these probes, the first argument is a uint64_t
stored in the xmm1 register.
Unfortunately, if I try to use this probe within GDB, then I can't
view the first argument. Here's an example session:
$ gdb $(which gdb)
(gdb) start
...
(gdb) info probes stap libc pthread_create
...
(gdb) break *0x00007ffff729e2f1 # Use address of probe.
(gdb) continue
...
(gdb) p $_probe_arg0
Invalid cast.
What's going wrong? If I re-run my session, but this time use 'set
debug stap-expression 1', this is what I see:
(gdb) set debug stap-expression 1
(gdb) p $_probe_arg0
Operation: UNOP_CAST
Operation: OP_REGISTER
String: xmm1
Type: uint64_t
Operation: UNOP_CAST
Operation: OP_REGISTER
String: r13
Type: uint64_t
Operation: UNOP_CAST
Operation: UNOP_IND
Operation: UNOP_CAST
Operation: BINOP_ADD
Operation: OP_LONG
Type: long
Constant: 0x0000000000000008
Operation: OP_REGISTER
String: rsp
Type: uint64_t *
Type: uint64_t
Operation: UNOP_CAST
Operation: UNOP_IND
Operation: UNOP_CAST
Operation: BINOP_ADD
Operation: OP_LONG
Type: long
Constant: 0x0000000000000010
Operation: OP_REGISTER
String: rsp
Type: uint64_t *
Type: uint64_t
Invalid cast.
(gdb)
The important bit is this:
Operation: UNOP_CAST
Operation: OP_REGISTER
String: xmm1
Type: uint64_t
Which is where we cast the xmm1 register to uint64_t. And the final
piece of the puzzle is:
(gdb) ptype $xmm1
type = union vec128 {
v8bf16 v8_bfloat16;
v4f v4_float;
v2d v2_double;
v16i8 v16_int8;
v8i16 v8_int16;
v4i32 v4_int32;
v2i64 v2_int64;
uint128_t uint128;
}
So, we are attempting to cast a union type to a scalar type, which is
not supporting in C/C++, and as a consequence GDB's expression
evaluator throws an error when we attempt to do this.
The first approach I considered for solving this problem was to try
and make use of gdbarch_stap_adjust_register. We already have a
gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak
the name of the register that we access. Currently only x86
architectures use this to transform things like ax to eax in some
cases.
I wondered, what if we change gdbarch_stap_adjust_register to do more
than just change the register names? What if this method instead
became gdbarch_stap_read_register. This new method would return a
operation_up, and would take the register name, and the type we are
trying to read from the register, and return the operation that
actually reads the register.
The default implementation of this method would just use
user_reg_map_name_to_regnum, and then create a register_operation,
like we already do in stap_parse_register_operand. But, for x86
architectures this method would fist possibly adjust the register
name, then do the default action to read the register. Finally, for
x86 this method would spot when we were accessing an xmm register,
and, based on the type being pulled from the register, would extract
the correct field from the union.
The benefit of this approach is that it would work with the expression
types that GDB currently supports. The draw back would be that this
approach would not be very generic. We'd need code to handle each
sub-field size with an xmm register. If other architectures started
using vector registers for probe arguments, those architectures would
have to create their own gdbarch_stap_read_register method. And
finally, the type of the xmm registers comes from the type defined in
the target description, there's a risk that GDB might end up
hard-coding the names of type sub-fields, then if a target uses a
different target description, with different field names for xmm
registers, the stap probes would stop working.
And so, based on all the above draw backs, I rejected this first
approach.
My second plan involves adding a new expression type to GDB called
unop_extract_operation. This new expression takes a value and a type,
during evaluation the value contents are fetched, and then a new value
is extracted from the value contents (based on type). This is similar
to the following C expression:
result_value = *((output_type *) &input_value);
Obviously we can't actually build this expression in this case, as the
input_value is in a register, but hopefully the above makes it clearer
what I'm trying to do.
The benefit of the new expression approach is that this code can be
shared across all architectures, and it doesn't care about sub-field
names within the union type.
The draw-backs that I see are potential future problems if arguments
are not stored within the least significant bytes of the register.
However if/when that becomes an issue we can adapt the
gdbarch_stap_read_register approach to allow architectures to control
how a value is extracted.
For testing, I've extended the existing gdb.base/stap-probe.exp test
to include a function that tries to force an argument into an xmm
register. Obviously, that will only work on a x86 target, so I've
guarded the new function with an appropriate GCC define. In the exp
script we use readelf to check if the probe exists, and is using the
xmm register.
If the probe doesn't exist then the associated tests are skipped.
If the probe exists, put isn't using the xmm register (which will
depend on systemtap/gcc versions), then again, the tests are skipped.
Otherwise, we can run the test. I think the cost of running readelf
is pretty low, so I don't feel too bad making all the non-xmm targets
running this step.
I found that on a Fedora 35 install, with these packages installed, I
was able to run this test and have the probe argument be placed in an
xmm register:
$ rpm -q systemtap gcc glibc
systemtap-4.6-4.fc35.x86_64
gcc-11.2.1-9.fc35.x86_64
glibc-2.34-7.fc35.x86_64
Finally, as this patch adds a new operation type, then I need to
consider how to generate an agent expression for the new operation
type.
I have kicked the can down the road a bit on this. In the function
stap_parse_register_operand, I only create a unop_extract_operation in
the case where the register type is non-scalar, this means that in
most cases I don't need to worry about generating an agent expression
at all.
In the xmm register case, when an unop_extract_operation will be
created, I have sketched out how the agent expression could be
handled, however, this code is currently not reached. When we try to
generate the agent expression to place the xmm register on the stack,
GDB hits this error:
(gdb) trace -probe-stap test:xmmreg
Tracepoint 1 at 0x401166
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $_probe_arg0
Value not scalar: cannot be an rvalue.
This is because GDB doesn't currently support placing non-scalar types
on the agent expression evaluation stack. Solving this is clearly
related to the original problem, but feels a bit like a second
problem. I'd like to get feedback on whether my approach to solving
the original problem is acceptable or not before I start looking at
how to handle xmm registers within agent expressions.
eval_op_concat has code to search for an operator overload of
BINOP_CONCAT. However, the operator overloading code is specific to
C++, which does not have this operator. And,
binop_types_user_defined_p rejects this case right at the start, and
value_x_binop does not handle this case. I think this code has been
dead for a very long time. This patch removes it and hoists the
remaining call into concatenation::evaluate, removing eval_op_concat
entirely.
eval_op_string is only used in a single place -- the implementation of
string_operation. This patch turns it into the
string_operation::evaluate method, removing a bit of extraneous code.
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.
This changes var_msym_value_operation to use a bound_minimal_symbol
rather than separate minsym and objfile parameters. The main benefit
of this is removing the possibly-confusing check_objfile overload for
a plain minimal symbol.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* parse.c (parser_state::push_symbol, parser_state::push_dollar):
Update.
* p-exp.y (variable): Update.
* go-exp.y (variable): Update.
* expprint.c (dump_for_expression): Use bound_minimal_symbol.
Remove overload for objfile.
* expop.h (eval_op_var_msym_value): Use bound_minimal_symbol
parameter.
(check_objfile): Likewise.
(dump_for_expression): Likewise. Remove overload for objfile.
(class var_msym_value_operation): Use bound_minimal_symbol.
* eval.c (eval_op_var_msym_value): Use bound_minimal_symbol
parameter.
(var_msym_value_operation::evaluate_for_address)
(var_msym_value_operation::evaluate_for_sizeof)
(var_msym_value_operation::evaluate_for_cast): Update.
* d-exp.y (PrimaryExpression): Update.
* c-exp.y (variable): Update.
* ax-gdb.c (var_msym_value_operation::do_generate_ax): Update.
* ada-lang.c (ada_var_msym_value_operation::evaluate_for_cast):
Update.
* ada-exp.y (write_var_or_type): Update.
This adds an expr::operation_up to struct expression, and then
modifies various parts of GDB to use this member when it is non-null.
The list of such spots was a bit surprising to me, and found only
after writing most of the code and then noticing what no longer
compiled.
In a few spots, new accessor methods are added to operation
subclasses, so that code that dissects an expression will work with
the new scheme.
After this change, code that constructs an expression can be switched
to the new form without breaking.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* ada-exp.h (class ada_var_value_operation) <get_symbol>: Remove;
now in superclass.
* value.h (fetch_subexp_value): Add "op" parameter.
* value.c (init_if_undefined_command): Update.
* tracepoint.c (validate_actionline, encode_actions_1): Update.
* stap-probe.c (stap_probe::compile_to_ax): Update.
* printcmd.c (set_command): Update.
* ppc-linux-nat.c (ppc_linux_nat_target::check_condition):
Update.
* parser-defs.h (struct expr_builder) <set_operation>: New
method.
* parse.c (parse_exp_in_context, exp_uses_objfile): Update.
* expression.h (struct expression) <first_opcode>: Update.
<op>: New member.
* expprint.c (dump_raw_expression, dump_prefix_expression):
Update.
* expop.h (class var_value_operation) <get_symbol>: New method.
(class register_operation) <get_name>: New method.
(class equal_operation): No longer a typedef, now a subclass.
(class unop_memval_operation) <get_type>: New method.
(class assign_operation) <get_lhs>: New method.
(class unop_cast_operation) <get_type>: New method.
* eval.c (evaluate_expression, evaluate_type)
(evaluate_subexpression_type): Update.
(fetch_subexp_value): Add "op" parameter.
(parse_and_eval_type): Update.
* dtrace-probe.c (dtrace_probe::compile_to_ax): Update.
* breakpoint.c (update_watchpoint, watchpoint_check)
(watchpoint_exp_is_const, watch_command_1): Update.
* ax-gdb.c (gen_trace_for_expr, gen_eval_for_expr, gen_printf):
Update.
Assignment is the most complicated Ada expression, because
implementing aggregate assignment involves several specialized
opcodes.
This patch does this implementation by introducing new abstract
classes that are used to represent the various parts of aggregate
assignment. This makes the code somewhat cleaner, and, by avoiding
the over-use of 'operation' subclasses, avoids the need for dissection
using dynamic_cast (though a few are still needed here).
I believe this patch fixes a latent bug in the handling of
aggregate_assign_from_choices. That code does:
if (op == OP_DISCRETE_RANGE)
{
choice_pos += 1;
lower = value_as_long (ada_evaluate_subexp (NULL, exp, pos,
EVAL_NORMAL));
upper = value_as_long (ada_evaluate_subexp (NULL, exp, pos,
EVAL_NORMAL));
}
However, I think 'choice_pos' should be used in the calls, rather than
'pos'.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expprint.c (dump_for_expression): New overload.
* expop.h (check_objfile, dump_for_expression): Declare new
overloads.
* ada-lang.c (check_objfile): New overload.
(assign_component, ada_aggregate_component::uses_objfile)
(ada_aggregate_component::dump, ada_aggregate_component::assign)
(ada_aggregate_component::assign_aggregate)
(ada_positional_component::uses_objfile)
(ada_positional_component::dump, ada_positional_component::assign)
(ada_discrete_range_association::uses_objfile)
(ada_discrete_range_association::dump)
(ada_discrete_range_association::assign)
(ada_name_association::uses_objfile, ada_name_association::dump)
(ada_name_association::assign)
(ada_choices_component::uses_objfile, ada_choices_component::dump)
(ada_choices_component::assign)
(ada_others_component::uses_objfile, ada_others_component::dump)
(ada_others_component::assign, ada_assign_operation::evaluate):
New methods.
* ada-exp.h (ada_string_operation) <get_name>: New method.
(class ada_assign_operation): New.
(class ada_component): New.
(ada_component_up): New typedef.
(class ada_aggregate_operation, class ada_aggregate_component)
(class ada_positional_component, class ada_others_component)
(class ada_association): New.
(ada_association_up): New typedef.
(class ada_choices_component)
(class ada_discrete_range_association)
(class ada_name_association): 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 implement function call operations.
The current function call code relies on some very lengthy code
(evaluate_funcall is 398 lines...) to distinguish between the
different opcodes that might appear in the callee position.
Rather than try to replicate this, and have a function that tried to
dissect many different kinds of operation subclass, this patch instead
puts the work into the callee. A new operation::evaluate_funcall
method is added, and then this is overridden in the classes that
require special treatment.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expression.h (class operation) <evaluate_funcall>: New methods.
* expop.h (class scope_operation) <evaluate_funcall>: New method.
(class var_value_operation) <evaluate_funcall>: New method.
(class structop_base_operation) <evaluate_funcall>: New method.
(class var_msym_value_operation) <evaluate_funcall>: New method.
(class structop_member_base): New class.
(class structop_member_operation): Derive from
structop_member_base.
(class structop_mptr_operation): Derive from
structop_member_base.
(class funcall_operation): New class.
* eval.c (operation::evaluate_funcall)
(var_value_operation::evaluate_funcall)
(scope_operation::evaluate_funcall)
(structop_member_base::evaluate_funcall)
(structop_base_operation::evaluate_funcall): New methods.
This adds class array_operation, which implements OP_ARRAY.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class array_operation): New.
* eval.c (array_operation::evaluate_struct_tuple)
(array_operation::evaluate): New methods.
This adds class adl_func_operation, which implements
argument-dependent lookup function calls.
Other function calls will be handled in a different way. However,
because ADL calls were created in a single spot in the C++ parser, and
because they had different semantics from the other cases, it was
convenient to treat them specially.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class adl_func_operation): New.
* eval.c (adl_func_operation::evaluate): New method.
This adds class multi_subscript_operation, which implements
MULTI_SUBSCRIPT.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class multi_subscript_operation): New.
* eval.c (multi_subscript_operation::evaluate): New method.
This adds class cxx_cast_operation, which is used to implement the C++
dynamic_cast and reinterpret_cast operations.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (cxx_cast_ftype): New typedef.
(cxx_cast_operation): New template.
(dynamic_cast_operation, reinterpret_cast_operation): New
typedefs.
This adds class unop_cast_type_operation, which implements
UNOP_CAST_TYPE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_cast_type_operation): New.
* ax-gdb.c (unop_cast_type_operation::do_generate_ax): New
method.
This adds class unop_cast_operation, which implements UNOP_CAST.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_cast_operation): New.
* ax-gdb.c (unop_cast_operation::do_generate_ax): New method.
This adds class assign_modify_operation, which implements
BINOP_ASSIGN_MODIFY.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class assign_modify_operation): New.
* eval.c (eval_binop_assign_modify): No longer static.
* ax-gdb.c (assign_modify_operation::do_generate_ax): New method.
This adds class assign_operation, which implements BINOP_ASSIGN.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class assign_operation): New.
* ax-gdb.c (assign_operation::do_generate_ax): New method.
This adds class type_instance_operation, which implements
TYPE_INSTANCE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class type_instance_operation): New.
* eval.c (type_instance_operation::evaluate): New method.
This adds class op_this_operation, which implements OP_THIS.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class op_this_operation): New.
* ax-gdb.c (op_this_operation::do_generate_ax): New method.
This adds class unop_memval_operation and unop_memval_type_operation,
which implement UNOP_MEMVAL and UNOP_MEMVAL_TYPE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_memval_operation)
(class unop_memval_type_operation): New.
* eval.c (eval_op_memval): No longer static.
(unop_memval_operation::evaluate_for_address)
(unop_memval_type_operation::evaluate_for_address)
(unop_memval_operation::evaluate_for_sizeof)
(unop_memval_type_operation::evaluate_for_sizeof): New methods.
* ax-gdb.c (unop_memval_operation::do_generate_ax)
(unop_memval_type_operation::do_generate_ax): New methods.
This adds class unop_alignof_operation, which implements UNOP_ALIGNOF.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_alignof_operation): New.
* eval.c (eval_op_alignof): No longer static.
This adds class unop_sizeof_operation, which implements UNOP_SIZEOF.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class unop_sizeof_operation): New.
* ax-gdb.c (unop_sizeof_operation::do_generate_ax): New method.
This adds class typeid_operation, which implements OP_TYPEID.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class typeid_operation): New.
This adds class decltype_operation, which implements OP_DECLTYPE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class decltype_operation): New.
This adds class typeof_operation, which implements OP_TYPEOF.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class typeof_operation): New.
This adds class type_operation, which implements OP_TYPE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expop.h (class type_operation): New.
* eval.c (eval_op_type): No longer static.
