2011-02-01 18:54:01 +00:00
|
|
|
/* Standard language operator definitions for GDB, the GNU debugger.
|
|
|
|
|
|
2023-01-01 16:49:04 +04:00
|
|
|
Copyright (C) 1986-2023 Free Software Foundation, Inc.
|
2011-02-01 18:54:01 +00:00
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
|
|
/* Used when it's necessary to pass an opcode which will be ignored,
|
|
|
|
|
or to catch uninitialized values. */
|
|
|
|
|
OP (OP_NULL)
|
|
|
|
|
|
|
|
|
|
/* BINOP_... operate on two values computed by following subexpressions,
|
|
|
|
|
replacing them by one result value. They take no immediate arguments. */
|
|
|
|
|
|
|
|
|
|
OP (BINOP_ADD) /* + */
|
|
|
|
|
OP (BINOP_SUB) /* - */
|
|
|
|
|
OP (BINOP_MUL) /* * */
|
|
|
|
|
OP (BINOP_DIV) /* / */
|
|
|
|
|
OP (BINOP_REM) /* % */
|
|
|
|
|
OP (BINOP_MOD) /* mod (Knuth 1.2.4) */
|
|
|
|
|
OP (BINOP_LSH) /* << */
|
|
|
|
|
OP (BINOP_RSH) /* >> */
|
|
|
|
|
OP (BINOP_LOGICAL_AND) /* && */
|
|
|
|
|
OP (BINOP_LOGICAL_OR) /* || */
|
|
|
|
|
OP (BINOP_BITWISE_AND) /* & */
|
|
|
|
|
OP (BINOP_BITWISE_IOR) /* | */
|
|
|
|
|
OP (BINOP_BITWISE_XOR) /* ^ */
|
|
|
|
|
OP (BINOP_EQUAL) /* == */
|
|
|
|
|
OP (BINOP_NOTEQUAL) /* != */
|
|
|
|
|
OP (BINOP_LESS) /* < */
|
|
|
|
|
OP (BINOP_GTR) /* > */
|
|
|
|
|
OP (BINOP_LEQ) /* <= */
|
|
|
|
|
OP (BINOP_GEQ) /* >= */
|
|
|
|
|
OP (BINOP_REPEAT) /* @ */
|
|
|
|
|
OP (BINOP_ASSIGN) /* = */
|
|
|
|
|
OP (BINOP_COMMA) /* , */
|
|
|
|
|
OP (BINOP_SUBSCRIPT) /* x[y] */
|
|
|
|
|
OP (BINOP_EXP) /* Exponentiation */
|
|
|
|
|
|
|
|
|
|
/* C++. */
|
|
|
|
|
|
|
|
|
|
OP (BINOP_MIN) /* <? */
|
|
|
|
|
OP (BINOP_MAX) /* >? */
|
|
|
|
|
|
|
|
|
|
/* STRUCTOP_MEMBER is used for pointer-to-member constructs.
|
|
|
|
|
X . * Y translates into X STRUCTOP_MEMBER Y. */
|
|
|
|
|
OP (STRUCTOP_MEMBER)
|
|
|
|
|
|
|
|
|
|
/* STRUCTOP_MPTR is used for pointer-to-member constructs
|
|
|
|
|
when X is a pointer instead of an aggregate. */
|
|
|
|
|
OP (STRUCTOP_MPTR)
|
|
|
|
|
|
|
|
|
|
/* TYPE_INSTANCE is used when the user specifies a specific
|
|
|
|
|
type instantiation for overloaded methods/functions.
|
|
|
|
|
|
|
|
|
|
The format is:
|
|
|
|
|
TYPE_INSTANCE num_types type0 ... typeN num_types TYPE_INSTANCE. */
|
|
|
|
|
OP (TYPE_INSTANCE)
|
|
|
|
|
|
|
|
|
|
/* end of C++. */
|
|
|
|
|
|
|
|
|
|
/* For Modula-2 integer division DIV. */
|
|
|
|
|
OP (BINOP_INTDIV)
|
|
|
|
|
|
|
|
|
|
/* +=, -=, *=, and so on. The following exp_element is another opcode,
|
|
|
|
|
a BINOP_, saying how to modify. Then comes another BINOP_ASSIGN_MODIFY,
|
|
|
|
|
making three exp_elements in total. */
|
|
|
|
|
OP (BINOP_ASSIGN_MODIFY)
|
|
|
|
|
|
|
|
|
|
/* Modula-2 standard (binary) procedures. */
|
|
|
|
|
OP (BINOP_VAL)
|
|
|
|
|
|
|
|
|
|
/* Concatenate two operands, such as character strings or bitstrings.
|
|
|
|
|
If the first operand is a integer expression, then it means concatenate
|
|
|
|
|
the second operand with itself that many times. */
|
|
|
|
|
OP (BINOP_CONCAT)
|
|
|
|
|
|
|
|
|
|
/* Operates on three values computed by following subexpressions. */
|
|
|
|
|
OP (TERNOP_COND) /* ?: */
|
|
|
|
|
|
2014-04-15 11:39:26 +08:00
|
|
|
/* A sub-string/sub-array. Ada syntax: OP1(OP2..OP3). Return
|
|
|
|
|
elements OP2 through OP3 of OP1. */
|
2011-02-01 18:54:01 +00:00
|
|
|
OP (TERNOP_SLICE)
|
|
|
|
|
|
|
|
|
|
/* Multidimensional subscript operator, such as Modula-2 x[a,b,...].
|
|
|
|
|
The dimensionality is encoded in the operator, like the number of
|
|
|
|
|
function arguments in OP_FUNCALL, I.E. <OP><dimension><OP>.
|
|
|
|
|
The value of the first following subexpression is subscripted
|
|
|
|
|
by each of the next following subexpressions, one per dimension. */
|
|
|
|
|
OP (MULTI_SUBSCRIPT)
|
|
|
|
|
|
|
|
|
|
/* The OP_... series take immediate following arguments.
|
|
|
|
|
After the arguments come another OP_... (the same one)
|
|
|
|
|
so that the grouping can be recognized from the end. */
|
|
|
|
|
|
|
|
|
|
/* OP_LONG is followed by a type pointer in the next exp_element
|
|
|
|
|
and the long constant value in the following exp_element.
|
|
|
|
|
Then comes another OP_LONG.
|
|
|
|
|
Thus, the operation occupies four exp_elements. */
|
|
|
|
|
OP (OP_LONG)
|
|
|
|
|
|
Target FP: Use target format throughout expression parsing
When parsing floating-point literals, the language parsers currently
use parse_float or some equivalent routine to parse the input string
into a DOUBLEST, which is then stored within a OP_DOUBLE expression
node. When evaluating the expression, the OP_DOUBLE is finally
converted into a value in target format.
On the other hand, *decimal* floating-point literals are parsed
directly into target format and stored that way in a OP_DECFLOAT
expression node. In order to eliminate the DOUBLEST, this patch
therefore unifies the handling of binary and decimal floating-
point literals and stores them both in target format within a
new OP_FLOAT expression node, replacing both OP_DOUBLE and
OP_DECFLOAT.
In order to store literals in target format, the parse_float
routine needs to know the type of the literal. All parsers
therefore need to be changed to determine the appropriate type
(e.g. by detecting suffixes) *before* calling parse_float,
instead of after it as today. However, this change is mostly
straightforward -- again, this is already done for decimal FP
today.
The core of the literal parsing is moved into a new routine
floatformat_from_string, mirroring floatformat_to_string.
The parse_float routine now calls either floatformat_from_string
or decimal_from_sting, allowing it to handle any type of FP
literal.
All language parsers need to be updated. Some notes on
specific changes to the various languages:
- C: Decimal FP is now handled in parse_float, and no longer
needs to be handled specially.
- D: Straightforward.
- Fortran: Still used a hard-coded "atof", also replaced by
parse_float now. Continues to always use builtin_real_s8
as the type of literal, even though this is probably wrong.
- Go: This used to handle "f" and "l" suffixes, even though
the Go language actually doesn't support those. I kept this
support for now -- maybe revisit later. Note the the GDB
test suite for some reason actually *verifies* that GDB supports
those unsupported suffixes ...
- Pascal: Likewise -- this handles suffixes that are not
supported in the language standard.
- Modula-2: Like Fortran, used to use "atof".
- Rust: Mostly straightforward, except for a unit-testing hitch.
The code use to set a special "unit_testing" flag which would
cause "rust_type" to always return NULL. This makes it not
possible to encode a literal into target format (which type?).
The reason for this flag appears to have been that during
unit testing, there is no "rust_parser" context set up, which
means no "gdbarch" is available to use its types. To fix this,
I removed the unit_testing flag, and instead simply just set up
a dummy rust_parser context during unit testing.
- Ada: This used to check sizeof (DOUBLEST) to determine which
type to use for floating-point literal. This seems questionable
to begin with (since DOUBLEST is quite unrelated to target formats),
and in any case we need to get rid of DOUBLEST. I'm now simply
always using the largest type (builtin_long_double).
gdb/ChangeLog:
2017-10-25 Ulrich Weigand <uweigand@de.ibm.com>
* doublest.c (floatformat_from_string): New function.
* doublest.h (floatformat_from_string): Add prototype.
* std-operator.def (OP_DOUBLE, OP_DECFLOAT): Remove, replace by ...
(OP_FLOAT): ... this.
* expression.h: Do not include "doublest.h".
(union exp_element): Replace doubleconst and decfloatconst by
new element floatconst.
* ada-lang.c (resolve_subexp): Handle OP_FLOAT instead of OP_DOUBLE.
(ada_evaluate_subexp): Likewise.
* eval.c (evaluate_subexp_standard): Handle OP_FLOAT instead of
OP_DOUBLE and OP_DECFLOAT.
* expprint.c (print_subexp_standard): Likewise.
(dump_subexp_body_standard): Likewise.
* breakpoint.c (watchpoint_exp_is_const): Likewise.
* parse.c: Include "dfp.h".
(write_exp_elt_dblcst, write_exp_elt_decfloatcst): Remove.
(write_exp_elt_floatcst): New function.
(operator_length_standard): Handle OP_FLOAT instead of OP_DOUBLE
and OP_DECFLOAT.
(operator_check_standard): Likewise.
(parse_float): Do not accept suffix. Take type as input. Return bool.
Return target format buffer instead of host DOUBLEST.
Use floatformat_from_string and decimal_from_string to parse
either binary or decimal floating-point types.
(parse_c_float): Remove.
* parser-defs.h: Do not include "doublest.h".
(write_exp_elt_dblcst, write_exp_elt_decfloatcst): Remove.
(write_exp_elt_floatcst): Add prototype.
(parse_float): Update prototype.
(parse_c_float): Remove.
* c-exp.y: Do not include "dfp.h".
(typed_val_float): Use byte buffer instead of DOUBLEST.
(typed_val_decfloat): Remove.
(DECFLOAT): Remove.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Update to new parse_float interface.
Parse suffixes and determine type before calling parse_float.
Handle decimal and binary FP types the same way.
* d-exp.y (typed_val_float): Use byte buffer instead of DOUBLEST.
(FLOAT_LITERAL): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Update to new parse_float interface.
Parse suffixes and determine type before calling parse_float.
* f-exp.y: Replace dval by typed_val_float.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Use parse_float instead of atof.
* go-exp.y (typed_val_float): Use byte buffer instead of DOUBLEST.
(parse_go_float): Remove.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Call parse_float instead of parse_go_float.
Parse suffixes and determine type before calling parse_float.
* p-exp.y (typed_val_float): Use byte buffer instead of DOUBLEST.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Update to new parse_float interface.
Parse suffixes and determine type before calling parse_float.
* m2-exp.y: Replace dval by byte buffer val.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
(parse_number): Call parse_float instead of atof.
* rust-exp.y (typed_val_float): Use byte buffer instead of DOUBLEST.
(lex_number): Call parse_float instead of strtod.
(ast_dliteral): Use OP_FLOAT instead of OP_DOUBLE.
(convert_ast_to_expression): Handle OP_FLOAT instead of OP_DOUBLE.
Use write_exp_elt_floatcst.
(unit_testing): Remove static variable.
(rust_type): Do not check unit_testing.
(rust_lex_tests): Do not set uint_testing. Set up dummy rust_parser.
* ada-exp.y (type_float, type_double): Remove.
(typed_val_float): Use byte buffer instead of DOUBLEST.
(FLOAT): Use OP_FLOAT and write_exp_elt_floatcst.
* ada-lex.l (processReal): Use parse_float instead of sscanf.
2017-10-25 15:32:23 +02:00
|
|
|
/* OP_FLOAT is similar but takes a floating-point constant encoded in
|
|
|
|
|
the target format for the given type instead of a long. */
|
|
|
|
|
OP (OP_FLOAT)
|
2011-02-01 18:54:01 +00:00
|
|
|
|
|
|
|
|
/* OP_VAR_VALUE takes one struct block * in the following element,
|
|
|
|
|
and one struct symbol * in the following exp_element, followed
|
|
|
|
|
by another OP_VAR_VALUE, making four exp_elements. If the
|
|
|
|
|
block is non-NULL, evaluate the symbol relative to the
|
|
|
|
|
innermost frame executing in that block; if the block is NULL
|
|
|
|
|
use the selected frame. */
|
|
|
|
|
OP (OP_VAR_VALUE)
|
|
|
|
|
|
2011-10-09 19:41:17 +00:00
|
|
|
/* OP_VAR_ENTRY_VALUE takes one struct symbol * in the following element,
|
|
|
|
|
followed by another OP_VAR_ENTRY_VALUE, making three exp_elements.
|
|
|
|
|
somename@entry may mean parameter value as present at the entry of the
|
DWARF-5: call sites
this patch updates all call sites related DWARF-5 renames.
gdb/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* block.c (call_site_for_pc): Rename DW_OP_GNU_*, DW_TAG_GNU_* and
DW_AT_GNU_*.
* common/common-exceptions.h (enum errors): Likewise.
* dwarf2-frame.c (class dwarf_expr_executor): Likewise.
* dwarf2expr.c (dwarf_block_to_dwarf_reg)
(dwarf_expr_context::execute_stack_op): Likewise.
* dwarf2expr.h (struct dwarf_expr_context, struct dwarf_expr_piece):
Likewise.
* dwarf2loc.c (dwarf_evaluate_loc_desc::get_base_type)
(dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value)
(show_entry_values_debug, call_site_to_target_addr)
(func_addr_to_tail_call_list, func_verify_no_selftailcall)
(dwarf_expr_reg_to_entry_parameter, dwarf_entry_parameter_to_value)
(entry_data_value_free_closure, value_of_dwarf_reg_entry)
(value_of_dwarf_block_entry, indirect_pieced_value)
(symbol_needs_eval_context::push_dwarf_reg_entry_value):
(disassemble_dwarf_expression): Likewise.
* dwarf2read.c (process_die, inherit_abstract_dies)
(read_call_site_scope): Likewise.
* gdbtypes.h (struct func_type, struct call_site_parameter)
(struct call_site): Likewise.
* stack.c (read_frame_arg): Likewise.
* std-operator.def (OP_VAR_ENTRY_VALUE): Likewise.
gdb/doc/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Print Settings, Tail Call Frames): Rename DW_OP_GNU_*,
DW_TAG_GNU_* and DW_AT_GNU_*.
gdb/testsuite/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-entry-value-param-dwarf5.S: New file.
* gdb.arch/amd64-entry-value-param-dwarf5.c: New file.
* gdb.arch/amd64-entry-value-param-dwarf5.exp: New file.
* gdb.arch/amd64-entry-value.exp: Rename DW_OP_GNU_*, DW_TAG_GNU_* and
DW_AT_GNU_*.
2017-02-20 20:53:21 +01:00
|
|
|
current function. Implemented via DW_OP_entry_value. */
|
2011-10-09 19:41:17 +00:00
|
|
|
OP (OP_VAR_ENTRY_VALUE)
|
|
|
|
|
|
Introduce OP_VAR_MSYM_VALUE
The previous patch left GDB with an inconsistency. While with normal
expression evaluation the "unknown return type" error shows the name
of the function that misses debug info:
(gdb) p getenv ("PATH")
'getenv' has unknown return type; cast the call to its declared return type
^^^^^^
which can by handy in more complicated expressions, "ptype" does not:
(gdb) ptype getenv ("PATH")
function has unknown return type; cast the call to its declared return type
^^^^^^^^
This commit is a step toward fixing it.
The problem is that while evaluating the expression above, we have no
reference to the minimal symbol where we could extract the name from.
This is because the resulting expression tree has no reference to the
minsym at all. During parsing, the type and address of the minsym are
extracted and an UNOP_MEMVAL / UNOP_MEMVAL_TLS operator is generated
(see write_exp_elt_msym). With "set debug expression", here's what
you see:
0 OP_FUNCALL Number of args: 0
3 UNOP_MEMVAL Type @0x565334a51930 (<text variable, no debug info>)
6 OP_LONG Type @0x565334a51c60 (__CORE_ADDR), value 140737345035648 (0x7ffff7751d80)
The "print" case finds the function name, because
call_function_by_hand looks up the function by address again.
However, for "ptype", we don't reach that code, because obviously we
don't really call the function.
Unlike minsym references, references to variables with debug info have
a pointer to the variable's symbol in the expression tree, with
OP_VAR_VALUE:
(gdb) ptype main()
...
0 OP_FUNCALL Number of args: 0
3 OP_VAR_VALUE Block @0x0, symbol @0x559bbbd9b358 (main(int, char**))
...
so I don't see why do minsyms need to be different. So to prepare for
fixing the missing function name issue, this commit adds a new
OP_VAR_MSYM_VALUE operator that mimics OP_VAR_VALUE, except that it's
for minsyms instead of debug symbols. For infcalls, we now get
expressions like these:
0 OP_FUNCALL Number of args: 0
3 OP_VAR_MSYM_VALUE Objfile @0x1e41bf0, msymbol @0x7fffe599b000 (getenv)
In the following patch, we'll make OP_FUNCALL extract the function
name from the symbol stored in OP_VAR_VALUE/OP_VAR_MSYM_VALUE.
OP_VAR_MSYM_VALUE will be used more in a later patch in the series
too.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* ada-lang.c (resolve_subexp): Handle OP_VAR_MSYM_VALUE.
* ax-gdb.c (gen_msym_var_ref): New function.
(gen_expr): Handle OP_VAR_MSYM_VALUE.
* eval.c (evaluate_var_msym_value): New function.
* eval.c (evaluate_subexp_standard): Handle OP_VAR_MSYM_VALUE.
<OP_FUNCALL>: Extract function name from symbol/minsym and pass it
to call_function_by_hand.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_VAR_MSYM_VALUE.
(union exp_element) <msymbol>: New field.
* minsyms.h (struct type): Forward declare.
(find_minsym_type_and_address): Declare.
* parse.c (write_exp_elt_msym): New function.
(write_exp_msymbol): Delete, refactored as ...
(find_minsym_type_and_address): ... this new function.
(write_exp_msymbol): Reimplement using OP_VAR_MSYM_VALUE.
(operator_length_standard, operator_check_standard): Handle
OP_VAR_MSYM_VALUE.
* std-operator.def (OP_VAR_MSYM_VALUE): New.
2017-09-04 20:21:13 +01:00
|
|
|
/* OP_VAR_MSYM_VALUE takes one struct objfile * in the following
|
|
|
|
|
element, and one struct minimal_symbol * in the following
|
|
|
|
|
exp_element, followed by another OP_VAR_MSYM_VALUE, making four
|
|
|
|
|
exp_elements. */
|
|
|
|
|
OP (OP_VAR_MSYM_VALUE)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* OP_LAST is followed by an integer in the next exp_element.
|
|
|
|
|
The integer is zero for the last value printed,
|
|
|
|
|
or it is the absolute number of a history element.
|
|
|
|
|
With another OP_LAST at the end, this makes three exp_elements. */
|
|
|
|
|
OP (OP_LAST)
|
|
|
|
|
|
|
|
|
|
/* OP_REGISTER is followed by a string in the next exp_element.
|
|
|
|
|
This is the name of a register to fetch. */
|
|
|
|
|
OP (OP_REGISTER)
|
|
|
|
|
|
|
|
|
|
/* OP_INTERNALVAR is followed by an internalvar ptr in the next
|
|
|
|
|
exp_element. With another OP_INTERNALVAR at the end, this
|
|
|
|
|
makes three exp_elements. */
|
|
|
|
|
OP (OP_INTERNALVAR)
|
|
|
|
|
|
|
|
|
|
/* OP_FUNCALL is followed by an integer in the next exp_element.
|
|
|
|
|
The integer is the number of args to the function call.
|
|
|
|
|
That many plus one values from following subexpressions
|
|
|
|
|
are used, the first one being the function.
|
|
|
|
|
The integer is followed by a repeat of OP_FUNCALL,
|
|
|
|
|
making three exp_elements. */
|
|
|
|
|
OP (OP_FUNCALL)
|
|
|
|
|
|
|
|
|
|
/* OP_OBJC_MSGCALL is followed by a string in the next exp_element
|
|
|
|
|
and then an integer. The string is the selector string. The
|
|
|
|
|
integer is the number of arguments to the message call. That
|
|
|
|
|
many plus one values are used, the first one being the object
|
|
|
|
|
pointer. This is an Objective C message. */
|
|
|
|
|
OP (OP_OBJC_MSGCALL)
|
|
|
|
|
|
|
|
|
|
/* OP_COMPLEX takes a type in the following element, followed by another
|
|
|
|
|
OP_COMPLEX, making three exp_elements. It is followed by two double
|
|
|
|
|
args, and converts them into a complex number of the given type. */
|
|
|
|
|
OP (OP_COMPLEX)
|
|
|
|
|
|
|
|
|
|
/* OP_STRING represents a string constant.
|
|
|
|
|
Its format is the same as that of a STRUCTOP, but the string
|
|
|
|
|
data is just made into a string constant when the operation
|
|
|
|
|
is executed. */
|
|
|
|
|
OP (OP_STRING)
|
|
|
|
|
|
|
|
|
|
/* OP_ARRAY creates an array constant out of the following subexpressions.
|
|
|
|
|
It is followed by two exp_elements, the first containing an integer
|
|
|
|
|
that is the lower bound of the array and the second containing another
|
|
|
|
|
integer that is the upper bound of the array. The second integer is
|
|
|
|
|
followed by a repeat of OP_ARRAY, making four exp_elements total.
|
|
|
|
|
The bounds are used to compute the number of following subexpressions
|
|
|
|
|
to consume, as well as setting the bounds in the created array constant.
|
|
|
|
|
The type of the elements is taken from the type of the first subexp,
|
|
|
|
|
and they must all match. */
|
|
|
|
|
OP (OP_ARRAY)
|
|
|
|
|
|
gdb/x86: handle stap probe arguments in xmm registers
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.
2022-03-10 11:57:18 -05:00
|
|
|
/* UNOP_EXTRACT takes a value and a type, like a cast, but, instead of
|
|
|
|
|
casting the value to the given type, a new value (of the given
|
|
|
|
|
type) is extracted from the contents of the old value, starting
|
|
|
|
|
from the least significant byte.
|
|
|
|
|
|
|
|
|
|
It is invalid for the given type to be larger than the type of the
|
|
|
|
|
given value. */
|
|
|
|
|
OP (UNOP_EXTRACT)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* UNOP_CAST is followed by a type pointer in the next exp_element.
|
|
|
|
|
With another UNOP_CAST at the end, this makes three exp_elements.
|
|
|
|
|
It casts the value of the following subexpression. */
|
|
|
|
|
OP (UNOP_CAST)
|
|
|
|
|
|
* ax-gdb.c (gen_expr): Handle UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE.
* breakpoint.c (watchpoint_exp_is_const): Handle UNOP_CAST_TYPE,
UNOP_REINTERPRET_CAST, UNOP_DYNAMIC_CAST.
* c-exp.y (exp): Emit UNOP_MEMVAL_TYPE, UNOP_CAST_TYPE. Update
for changes to UNOP_REINTERPRET_CAST, UNOP_DYNAMIC_CAST. Use
type_exp production where appropriate.
* eval.c (evaluate_subexp_standard) <UNOP_CAST_TYPE>: New case.
<UNOP_DYNAMIC_CAST, UNOP_REINTERPRET_CAST>: Update.
<UNOP_MEMVAL_TYPE>: New case.
(evaluate_subexp_for_address) <UNOP_MEMVAL_TYPE>: New case.
(evaluate_subexp_for_sizeof) <UNOP_MEMVAL_TYPE>: New case.
* expprint.c (print_subexp_standard) <UNOP_CAST_TYPE>: New case.
<UNOP_MEMVAL_TYPE>: New case.
(dump_subexp_body_standard) <UNOP_DYNAMIC_CAST,
UNOP_REINTERPRET_CAST>: Update.
<UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE>: New cases.
* parse.c (operator_length_standard) <UNOP_DYNAMIC_CAST,
UNOP_REINTERPRET_CAST>: Update.
<UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE>: New cases.
* stack.c (return_command): Also check for UNOP_CAST_TYPE.
* std-operator.def (UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE): New
constants.
2012-07-19 15:33:25 +00:00
|
|
|
/* Like UNOP_CAST, but the type is a subexpression. */
|
|
|
|
|
OP (UNOP_CAST_TYPE)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* The C++ dynamic_cast operator. */
|
|
|
|
|
OP (UNOP_DYNAMIC_CAST)
|
|
|
|
|
|
|
|
|
|
/* The C++ reinterpret_cast operator. */
|
|
|
|
|
OP (UNOP_REINTERPRET_CAST)
|
|
|
|
|
|
|
|
|
|
/* UNOP_MEMVAL is followed by a type pointer in the next exp_element
|
|
|
|
|
With another UNOP_MEMVAL at the end, this makes three exp_elements.
|
|
|
|
|
It casts the contents of the word addressed by the value of the
|
|
|
|
|
following subexpression. */
|
|
|
|
|
OP (UNOP_MEMVAL)
|
|
|
|
|
|
* ax-gdb.c (gen_expr): Handle UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE.
* breakpoint.c (watchpoint_exp_is_const): Handle UNOP_CAST_TYPE,
UNOP_REINTERPRET_CAST, UNOP_DYNAMIC_CAST.
* c-exp.y (exp): Emit UNOP_MEMVAL_TYPE, UNOP_CAST_TYPE. Update
for changes to UNOP_REINTERPRET_CAST, UNOP_DYNAMIC_CAST. Use
type_exp production where appropriate.
* eval.c (evaluate_subexp_standard) <UNOP_CAST_TYPE>: New case.
<UNOP_DYNAMIC_CAST, UNOP_REINTERPRET_CAST>: Update.
<UNOP_MEMVAL_TYPE>: New case.
(evaluate_subexp_for_address) <UNOP_MEMVAL_TYPE>: New case.
(evaluate_subexp_for_sizeof) <UNOP_MEMVAL_TYPE>: New case.
* expprint.c (print_subexp_standard) <UNOP_CAST_TYPE>: New case.
<UNOP_MEMVAL_TYPE>: New case.
(dump_subexp_body_standard) <UNOP_DYNAMIC_CAST,
UNOP_REINTERPRET_CAST>: Update.
<UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE>: New cases.
* parse.c (operator_length_standard) <UNOP_DYNAMIC_CAST,
UNOP_REINTERPRET_CAST>: Update.
<UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE>: New cases.
* stack.c (return_command): Also check for UNOP_CAST_TYPE.
* std-operator.def (UNOP_CAST_TYPE, UNOP_MEMVAL_TYPE): New
constants.
2012-07-19 15:33:25 +00:00
|
|
|
/* Like UNOP_MEMVAL, but the type is supplied as a subexpression. */
|
|
|
|
|
OP (UNOP_MEMVAL_TYPE)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* UNOP_... operate on one value from a following subexpression
|
|
|
|
|
and replace it with a result. They take no immediate arguments. */
|
|
|
|
|
|
|
|
|
|
OP (UNOP_NEG) /* Unary - */
|
|
|
|
|
OP (UNOP_LOGICAL_NOT) /* Unary ! */
|
|
|
|
|
OP (UNOP_COMPLEMENT) /* Unary ~ */
|
|
|
|
|
OP (UNOP_IND) /* Unary * */
|
|
|
|
|
OP (UNOP_ADDR) /* Unary & */
|
|
|
|
|
OP (UNOP_PREINCREMENT) /* ++ before an expression */
|
|
|
|
|
OP (UNOP_POSTINCREMENT) /* ++ after an expression */
|
|
|
|
|
OP (UNOP_PREDECREMENT) /* -- before an expression */
|
|
|
|
|
OP (UNOP_POSTDECREMENT) /* -- after an expression */
|
|
|
|
|
OP (UNOP_SIZEOF) /* Unary sizeof (followed by expression) */
|
2018-04-20 13:40:29 -06:00
|
|
|
OP (UNOP_ALIGNOF) /* Unary alignof (followed by expression) */
|
2011-02-01 18:54:01 +00:00
|
|
|
|
|
|
|
|
OP (UNOP_PLUS) /* Unary plus */
|
|
|
|
|
|
|
|
|
|
OP (UNOP_ABS)
|
|
|
|
|
OP (UNOP_HIGH)
|
|
|
|
|
|
|
|
|
|
OP (OP_BOOL) /* Modula-2 builtin BOOLEAN type */
|
|
|
|
|
|
|
|
|
|
/* STRUCTOP_... operate on a value from a following subexpression
|
|
|
|
|
by extracting a structure component specified by a string
|
|
|
|
|
that appears in the following exp_elements (as many as needed).
|
|
|
|
|
STRUCTOP_STRUCT is used for "." and STRUCTOP_PTR for "->".
|
|
|
|
|
They differ only in the error message given in case the value is
|
|
|
|
|
not suitable or the structure component specified is not found.
|
|
|
|
|
|
|
|
|
|
The length of the string follows the opcode, followed by
|
|
|
|
|
BYTES_TO_EXP_ELEM(length) elements containing the data of the
|
|
|
|
|
string, followed by the length again and the opcode again. */
|
|
|
|
|
|
|
|
|
|
OP (STRUCTOP_STRUCT)
|
|
|
|
|
OP (STRUCTOP_PTR)
|
|
|
|
|
|
2016-04-26 19:38:08 -06:00
|
|
|
/* Anonymous field access, e.g. "foo.3". Used in Rust. */
|
|
|
|
|
OP (STRUCTOP_ANONYMOUS)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* C++: OP_THIS is just a placeholder for the class instance variable.
|
|
|
|
|
It just comes in a tight (OP_THIS, OP_THIS) pair. */
|
|
|
|
|
OP (OP_THIS)
|
|
|
|
|
|
|
|
|
|
/* Objective C: "@selector" pseudo-operator. */
|
|
|
|
|
OP (OP_OBJC_SELECTOR)
|
|
|
|
|
|
|
|
|
|
/* OP_SCOPE surrounds a type name and a field name. The type
|
|
|
|
|
name is encoded as one element, but the field name stays as
|
|
|
|
|
a string, which, of course, is variable length. */
|
|
|
|
|
OP (OP_SCOPE)
|
|
|
|
|
|
Handle "p S::method()::static_var" in the C++ parser
This commit makes "print S::method()::static_var" actually find the
debug symbol for static_var. Currently, you get:
(gdb) print S::method()::static_var
A syntax error in expression, near `'.
Quoting the whole string would seemingly work before the previous
patch that made GDB stop assuming int for no-debug-info variables:
(gdb) p 'S::method()::static_var'
$1 = 1
... except that's incorrect output, because:
(gdb) ptype 'S::method()::static_var'
type = <data variable, no debug info>
The way to make it work correctly currently is by quoting the
function/method part, like this:
(gdb) print 'S::method()'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype 'S::method()'::static_var
type = struct aggregate {
int i1;
int i2;
int i3;
}
At least after the "stop assuming int" patch, this is what we
now get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
(gdb) p (struct aggregate) 'S::method()::static_var'
$1 = {i1 = 1, i2 = 2, i3 = 3}
However, IMO, users shouldn't really have to care about any of this.
GDB should Just Work, without quoting, IMO.
So here's a patch that implements support for that in the C++ parser.
With this patch, you now get:
(gdb) p S::method()::S_M_s_var_aggregate
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype S::method()::S_M_s_var_aggregate
type = struct aggregate {
int i1;
int i2;
int i3;
}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
(%type <voidval>): Add function_method.
* c-exp.y (exp): New production for calls with no arguments.
(function_method, function_method_void_or_typelist): New
productions.
(exp): New production for "method()::static_var".
* eval.c (evaluate_subexp_standard): Handle OP_FUNC_STATIC_VAR.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_FUNC_STATIC_VAR.
* parse.c (operator_length_standard):
Handle OP_FUNC_STATIC_VAR.
* std-operator.def (OP_FUNC_STATIC_VAR): New.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.c: New.
* gdb.base/local-static.cc: New.
* gdb.base/local-static.exp: New.
2017-09-04 20:21:15 +01:00
|
|
|
/* OP_FUNC_STATIC_VAR refers to a function local static variable. The
|
|
|
|
|
function is taken from the following subexpression. The length of
|
|
|
|
|
the variable name as a string follows the opcode, followed by
|
|
|
|
|
BYTES_TO_EXP_ELEM(length) elements containing the data of the
|
|
|
|
|
string, followed by the length again and the opcode again.
|
|
|
|
|
|
|
|
|
|
Note this is used by C++, but not C. The C parser handles local
|
|
|
|
|
static variables in the parser directly. Also, this is only used
|
|
|
|
|
in C++ if the function/method name is not quoted, like e.g.:
|
|
|
|
|
|
|
|
|
|
p S:method()::var
|
|
|
|
|
p S:method() const::var
|
|
|
|
|
|
|
|
|
|
If the function/method is quoted like instead:
|
|
|
|
|
|
|
|
|
|
p 'S:method() const'::var
|
|
|
|
|
|
|
|
|
|
then the C-specific handling directly in the parser takes over (see
|
2019-03-30 17:14:23 +00:00
|
|
|
block/variable productions).
|
Handle "p 'S::method()::static_var'" (quoted) in symbol lookup
While the previous commit made "p method()::static_var" (no
single-quotes) Just Work, if users (or frontends) try wrapping the
expression with quotes, they'll get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
even if we _do_ have debug info for that variable. That's better than
the bogus/confusing value what GDB would print before the
stop-assuming-int patch:
(gdb) p 'S::method()::static_var'
$1 = 1
but I think it'd still be nice to make this case Just Work too.
In this case, due to the quoting, the C/C++ parser (c-exp.y)
interprets the whole expression/string as a single symbol name, and we
end up calling lookup_symbol on that name. There's no debug symbol
with that fully-qualified name, but since the compiler gives the
static variable a mangled linkage name exactly like the above, it
appears in the mininal symbols:
$ nm -A local-static | c++filt | grep static_var
local-static:0000000000601040 d S::method()::static_var
... and that's what GDB happens to find/print. This only happens in
C++, note, since for C the compiler uses different linkage names:
local-static-c:0000000000601040 d static_var.1848
So while (in C++, not C) function local static variables are given a
mangled name that demangles to the same syntax that GDB
documents/expects as the way to access function local statics, there's
no global symbol in the debug info with that name at all. The debug
info for a static local variable for a non-inline function looks like
this:
<1><2a1>: Abbrev Number: 19 (DW_TAG_subprogram)
...
<2><2f7>: Abbrev Number: 20 (DW_TAG_variable)
<2f8> DW_AT_name : (indirect string, offset: 0x4e9): static_var
<2fc> DW_AT_decl_file : 1
<2fd> DW_AT_decl_line : 64
<2fe> DW_AT_type : <0x25>
<302> DW_AT_location : 9 byte block: 3 40 10 60 0 0 0 0 0 (DW_OP_addr: 601040)
and for an inline function, it looks like this (linkage name run
through c++filt for convenience):
<2><21b>: Abbrev Number: 16 (DW_TAG_variable)
<21c> DW_AT_name : (indirect string, offset: 0x21a): static_var
<220> DW_AT_decl_file : 1
<221> DW_AT_decl_line : 48
<222> DW_AT_linkage_name: (indirect string, offset: 0x200): S::inline_method()::static_var
<226> DW_AT_type : <0x25>
<22a> DW_AT_external : 1
<22a> DW_AT_location : 9 byte block: 3 a0 10 60 0 0 0 0 0 (DW_OP_addr: 6010a0)
(The inline case makes the variable external so that the linker can
merge the different inlined copies. It seems like GCC never outputs
the linkage name for non-extern globals.)
When we read the DWARF, we record the static_var variable as a regular
variable of the containing function's block. This makes stopping in
the function and printing the variable as usual. The variable just so
happens to have a memory address as location.
So one way to make "p 'S::method()::static_var'" work would be to
record _two_ copies of the symbols for these variables. One in the
function's scope/block, with "static_var" as name, as we currently do,
and another in the static or global blocks (depending on whether the
symbol is external), with a fully-qualified name. I wrote a prototype
patch for that, and it works. For the non-inline case above, since
the debug info doesn't point to the linkage same, that patch built the
physname of the static local variable as the concat of the physname of
the containing function, plus "::", plus the variable's name. We
could make that approach work for C too, though it kind of feels
awkward to record fake symbol names like that in C.
The other approach I tried is to change the C++ symbol lookup routines
instead. This is the approach this commit takes. We can already
lookup up symbol in namespaces and classes, so this feels like a good
fit, and was easy enough. The advantage is that this doesn't require
recording extra symbols.
The test in gdb.cp/m-static.exp that exposed the need for this is
removed, since the same functionality is now covered by
gdb.cp/local-static.exp.
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* cp-namespace.c (cp_search_static_and_baseclasses): Handle
function/method scopes; lookup the nested name as a function local
static variable.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.exp: Also test with
class::method::variable wholly quoted.
* gdb.cp/m-static.exp (class::method::variable): Remove test.
2017-09-04 20:21:16 +01:00
|
|
|
|
|
|
|
|
Also, if the whole function+var is quoted like this:
|
|
|
|
|
|
|
|
|
|
p 'S:method() const::var'
|
|
|
|
|
|
|
|
|
|
then the whole quoted expression is interpreted as a single symbol
|
|
|
|
|
name and we don't use OP_FUNC_STATIC_VAR either. In that case, the
|
|
|
|
|
C++-specific symbol lookup routines take care of the
|
|
|
|
|
function-local-static search. */
|
Handle "p S::method()::static_var" in the C++ parser
This commit makes "print S::method()::static_var" actually find the
debug symbol for static_var. Currently, you get:
(gdb) print S::method()::static_var
A syntax error in expression, near `'.
Quoting the whole string would seemingly work before the previous
patch that made GDB stop assuming int for no-debug-info variables:
(gdb) p 'S::method()::static_var'
$1 = 1
... except that's incorrect output, because:
(gdb) ptype 'S::method()::static_var'
type = <data variable, no debug info>
The way to make it work correctly currently is by quoting the
function/method part, like this:
(gdb) print 'S::method()'::static_var
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype 'S::method()'::static_var
type = struct aggregate {
int i1;
int i2;
int i3;
}
At least after the "stop assuming int" patch, this is what we
now get:
(gdb) p 'S::method()::static_var'
'S::method()::static_var' has unknown type; cast it to its declared type
(gdb) p (struct aggregate) 'S::method()::static_var'
$1 = {i1 = 1, i2 = 2, i3 = 3}
However, IMO, users shouldn't really have to care about any of this.
GDB should Just Work, without quoting, IMO.
So here's a patch that implements support for that in the C++ parser.
With this patch, you now get:
(gdb) p S::method()::S_M_s_var_aggregate
$1 = {i1 = 1, i2 = 2, i3 = 3}
(gdb) ptype S::method()::S_M_s_var_aggregate
type = struct aggregate {
int i1;
int i2;
int i3;
}
gdb/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
(%type <voidval>): Add function_method.
* c-exp.y (exp): New production for calls with no arguments.
(function_method, function_method_void_or_typelist): New
productions.
(exp): New production for "method()::static_var".
* eval.c (evaluate_subexp_standard): Handle OP_FUNC_STATIC_VAR.
* expprint.c (print_subexp_standard, dump_subexp_body_standard):
Handle OP_FUNC_STATIC_VAR.
* parse.c (operator_length_standard):
Handle OP_FUNC_STATIC_VAR.
* std-operator.def (OP_FUNC_STATIC_VAR): New.
gdb/testsuite/ChangeLog:
2017-09-04 Pedro Alves <palves@redhat.com>
* gdb.base/local-static.c: New.
* gdb.base/local-static.cc: New.
* gdb.base/local-static.exp: New.
2017-09-04 20:21:15 +01:00
|
|
|
OP (OP_FUNC_STATIC_VAR)
|
|
|
|
|
|
2011-02-01 18:54:01 +00:00
|
|
|
/* OP_TYPE is for parsing types, and used with the "ptype" command
|
|
|
|
|
so we can look up types that are qualified by scope, either with
|
|
|
|
|
the GDB "::" operator, or the Modula-2 '.' operator. */
|
|
|
|
|
OP (OP_TYPE)
|
|
|
|
|
|
|
|
|
|
/* An Objective C Foundation Class NSString constant. */
|
|
|
|
|
OP (OP_OBJC_NSSTRING)
|
|
|
|
|
|
2016-04-27 10:28:56 -06:00
|
|
|
/* An array range operator (in Fortran 90, for "exp:exp", "exp:",
|
|
|
|
|
":exp" and ":"). */
|
|
|
|
|
OP (OP_RANGE)
|
2011-02-01 18:54:01 +00:00
|
|
|
|
|
|
|
|
/* OP_ADL_FUNC specifies that the function is to be looked up in an
|
|
|
|
|
Argument Dependent manner (Koenig lookup). */
|
|
|
|
|
OP (OP_ADL_FUNC)
|
PR exp/13206:
* ax-gdb.c (gen_expr) <OP_TYPEOF, OP_DECLTYPE>: New cases.
* breakpoint.c (watchpoint_exp_is_const) <OP_TYPEOF,
OP_DECLTYPE>: New cases.
* c-exp.y (TYPEOF, DECLTYPE): New tokens.
(type_exp): Add new productions.
(ident_tokens): Add __typeof__, typeof, __typeof, __decltype,
and decltype.
* eval.c (evaluate_subexp_standard) <OP_TYPEOF, OP_DECLTYPE>:
New case.
* expprint.c (dump_subexp_body_standard) <OP_TYPEOF,
OP_DECLTYPE>: New case.
* parse.c (operator_length_standard) <OP_TYPEOF, OP_DECLTYPE>:
New case.
* std-operator.def (OP_TYPEOF, OP_DECLTYPE): New constants.
* varobj.c (varobj_create): Handle OP_TYPEOF, OP_DECLTYPE.
gdb/testsuite
* gdb.cp/casts.exp: Add tests for typeof and decltype.
* gdb.cp/casts.cc (decltype): New function.
(main): Use it.
2012-07-19 15:38:18 +00:00
|
|
|
|
|
|
|
|
/* The typeof operator. This has one expression argument, which is
|
|
|
|
|
evaluated solely for its type. */
|
|
|
|
|
OP (OP_TYPEOF)
|
|
|
|
|
|
|
|
|
|
/* The decltype operator. This has one expression argument, which is
|
|
|
|
|
evaluated solely for its type. This is similar to typeof, but has
|
|
|
|
|
slight different semantics. */
|
|
|
|
|
OP (OP_DECLTYPE)
|
2013-04-15 17:36:14 +00:00
|
|
|
|
|
|
|
|
/* The typeid operator. This has one expression argument. */
|
|
|
|
|
OP (OP_TYPEID)
|
2016-04-26 19:38:08 -06:00
|
|
|
|
|
|
|
|
/* This is used for the Rust [expr; N] form of array construction. It
|
|
|
|
|
takes two expression arguments. */
|
|
|
|
|
OP (OP_RUST_ARRAY)
|
2020-12-09 13:43:44 -07:00
|
|
|
|
|
|
|
|
/* ================ Ada operators ================ */
|
|
|
|
|
|
|
|
|
|
/* X IN A'RANGE(N). N is an immediate operand, surrounded by
|
|
|
|
|
BINOP_IN_BOUNDS before and after. A is an array, X an index
|
|
|
|
|
value. Evaluates to true iff X is within range of the Nth
|
|
|
|
|
dimension (1-based) of A. (A multi-dimensional array
|
|
|
|
|
type is represented as array of array of ...) */
|
|
|
|
|
OP (BINOP_IN_BOUNDS)
|
|
|
|
|
|
|
|
|
|
/* X IN L .. U. True iff L <= X <= U. */
|
|
|
|
|
OP (TERNOP_IN_RANGE)
|
|
|
|
|
|
|
|
|
|
/* Ada attributes ('Foo). */
|
|
|
|
|
OP (OP_ATR_FIRST)
|
|
|
|
|
OP (OP_ATR_LAST)
|
|
|
|
|
OP (OP_ATR_LENGTH)
|
|
|
|
|
OP (OP_ATR_POS)
|
|
|
|
|
OP (OP_ATR_SIZE)
|
|
|
|
|
OP (OP_ATR_TAG)
|
|
|
|
|
OP (OP_ATR_VAL)
|
|
|
|
|
|
|
|
|
|
/* Ada type qualification. It is encoded as for UNOP_CAST, above,
|
|
|
|
|
and denotes the TYPE'(EXPR) construct. */
|
|
|
|
|
OP (UNOP_QUAL)
|
|
|
|
|
|
|
|
|
|
/* X IN TYPE. The `TYPE' argument is immediate, with
|
|
|
|
|
UNOP_IN_RANGE before and after it. True iff X is a member of
|
|
|
|
|
type TYPE (typically a subrange). */
|
|
|
|
|
OP (UNOP_IN_RANGE)
|
|
|
|
|
|
|
|
|
|
/* An aggregate. A single immediate operand, N>0, gives
|
|
|
|
|
the number of component specifications that follow. The
|
|
|
|
|
immediate operand is followed by a second OP_AGGREGATE.
|
|
|
|
|
Next come N component specifications. A component
|
|
|
|
|
specification is either an OP_OTHERS (others=>...), an
|
|
|
|
|
OP_CHOICES (for named associations), or other expression (for
|
|
|
|
|
positional aggregates only). Aggregates currently
|
|
|
|
|
occur only as the right sides of assignments. */
|
|
|
|
|
OP (OP_AGGREGATE)
|
|
|
|
|
|
|
|
|
|
/* ================ Fortran operators ================ */
|
|
|
|
|
|
|
|
|
|
/* This is EXACTLY like OP_FUNCALL but is semantically different.
|
|
|
|
|
In F77, array subscript expressions, substring expressions and
|
|
|
|
|
function calls are all exactly the same syntactically. They
|
|
|
|
|
may only be disambiguated at runtime. Thus this operator,
|
|
|
|
|
which indicates that we have found something of the form
|
|
|
|
|
<name> ( <stuff> ). */
|
|
|
|
|
OP (OP_F77_UNDETERMINED_ARGLIST)
|
|
|
|
|
|
|
|
|
|
/* Single operand builtins. */
|
|
|
|
|
OP (UNOP_FORTRAN_KIND)
|
2021-02-11 13:34:06 +00:00
|
|
|
OP (UNOP_FORTRAN_ALLOCATED)
|
2021-02-25 11:41:57 +00:00
|
|
|
OP (UNOP_FORTRAN_RANK)
|
2021-02-26 11:14:24 +00:00
|
|
|
OP (UNOP_FORTRAN_SHAPE)
|
2021-03-09 11:34:55 +01:00
|
|
|
OP (UNOP_FORTRAN_LOC)
|
2020-12-09 13:43:44 -07:00
|
|
|
|
|
|
|
|
/* Two operand builtins. */
|
|
|
|
|
OP (BINOP_FORTRAN_MODULO)
|
2021-02-09 15:46:13 +00:00
|
|
|
|
|
|
|
|
/* Builtins that take one or two operands. */
|
gdb/fortran: rewrite intrinsic handling and add some missing overloads
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.
2022-04-11 14:06:56 +02:00
|
|
|
OP (FORTRAN_CEILING)
|
|
|
|
|
OP (FORTRAN_FLOOR)
|
|
|
|
|
OP (FORTRAN_ASSOCIATED)
|
|
|
|
|
|
|
|
|
|
/* Builtins that take one, two or three operands. */
|
2021-02-09 15:46:13 +00:00
|
|
|
OP (FORTRAN_LBOUND)
|
|
|
|
|
OP (FORTRAN_UBOUND)
|
gdb/fortran: rewrite intrinsic handling and add some missing overloads
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.
2022-04-11 14:06:56 +02:00
|
|
|
OP (FORTRAN_CMPLX)
|
2021-03-09 11:34:55 +01:00
|
|
|
OP (FORTRAN_ARRAY_SIZE)
|