aboutsummaryrefslogtreecommitdiff
path: root/gdb/eval.c
AgeCommit message (Collapse)AuthorFilesLines
2022-04-04Add context-sensitive field name completion to Ada parserTom Tromey1-8/+10
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
2022-04-04Refactor expression completionTom Tromey1-0/+85
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.
2022-03-21gdb/x86: handle stap probe arguments in xmm registersAndrew Burgess1-0/+16
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-16Remove eval_op_concatTom Tromey1-12/+0
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.
2022-03-16Remove eval_op_stringTom Tromey1-5/+10
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.
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-9/+9
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-1/+1
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
2022-01-03Small indentation fix in eval.cTom Tromey1-1/+1
I noticed that the AdaCore tree had a small divergence in eval.c -- it had a fix for an indentation problem in binop_promote. I'm checking in this small fix as obvious.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-10-29gdb: remove TYPE_FIELD_BITPOSSimon Marchi1-1/+1
Remove TYPE_FIELD_BITPOS, replace its uses with type::field + field::loc_bitpos. Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320
2021-10-25gdb: change functions returning value contents to use gdb::array_viewSimon Marchi1-7/+7
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
2021-09-30gdb: remove TYPE_FIELD_NAME and FIELD_NAME macrosSimon Marchi1-1/+1
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the call sites to use field::name directly. Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
2021-09-24Move value_true to value.hTom Tromey1-2/+2
I noticed that value_true is declared in language.h and defined in language.c. However, as part of the value API, I think it would be better in one of those files. And, because it is very short, I changed it to be an inline function in value.h. I've also removed a comment from the implementation, on the basis that it seems obsolete -- if the change it suggests was needed, it probably would have been done by now; and if it is needed in the future, odds are it would be done differently anyway. Finally, this patch also changes value_true and value_logical_not to return a bool, and updates some uses.
2021-09-23Change pointer_type to a method of struct typeTom Tromey1-6/+3
I noticed that pointer_type is declared in language.h and defined in language.c. However, it really has to do with types, so it should have been in gdbtypes.h all along. This patch changes it to be a method on struct type. And, I went through uses of TYPE_IS_REFERENCE and updated many spots to use the new method as well. (I didn't update ones that were in arch-specific code, as I couldn't readily test that.)
2021-06-25gdb: use gdb::optional instead of passing a pointer to gdb::array_viewAndrew Burgess1-3/+3
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.
2021-06-25gdb: replace NULL terminated array with array_viewAndrew Burgess1-11/+8
After the previous commit, this commit updates the value_struct_elt function to take an array_view rather than a NULL terminated array of values. The requirement for a NULL terminated array of values actually stems from typecmp, so the change from an array to array_view needs to be propagated through to this function. While making this change I noticed that this fixes another bug, in value_x_binop and value_x_unop GDB creates an array of values which doesn't have a NULL at the end. An array_view of this array is passed to value_user_defined_op, which then unpacks the array_view and passed the raw array to value_struct_elt, but only if the language is not C++. As value_x_binop and value_x_unop can only request member functions with the names of C++ operators, then most of the time, assuming the inferior is not a C++ program, then GDB will not find a matching member function with the call to value_struct_elt, and so typecmp will never be called, and so, GDB will avoid undefined behaviour. However, it is worth remembering that, when GDB's language is set to "auto", the current language is selected based on the language of the current compilation unit. As C++ programs usually link against libc, which is written in C, then, if the inferior is stopped in libc GDB will set the language to C. And so, it is possible that we will end up using value_struct_elt to try and lookup, and match, a C++ operator. If this occurs then GDB will experience undefined behaviour. I have extended the test added in the previous commit to also cover this case. Finally, this commit changes the API from passing around a pointer to an array to passing around a pointer to an array_view. The reason for this is that we need to be able to distinguish between the cases where we call value_struct_elt with no arguments, i.e. we are looking up a struct member, but we either don't have the arguments we want to pass yet, or we don't expect there to be any need for GDB to use the argument types to resolve any overloading; and the second case where we call value_struct_elt looking for a function that takes no arguments, that is, the argument list is empty. NOTE: While writing this I realise that if we pass an array_view at all then it will always have at least one item in it, the `this' pointer for the object we are planning to call the method on. So we could, I guess, pass an empty array_view to indicate the case where we don't know anything about the arguments, and when the array_view is length 1 or more, it means we do have the arguments. However, though we could do this, I don't think this would be better, the length 0 vs length 1 difference seems a little too subtle, I think that there's a better solution... I think a better solution would be to wrap the array_view in a gdb::optional, this would make the whole, do we have an array view or not question explicit. I haven't done this as part of this commit as making that change is much more extensive, every user of value_struct_elt will need to be updated, and as this commit already contains a bug fix, I wanted to keep the large refactoring in a separate commit, so, check out the next commit for the use of gdb::optional. gdb/ChangeLog: PR gdb/27994 * eval.c (structop_base_operation::evaluate_funcall): Pass array_view instead of array to value_struct_elt. * valarith.c (value_user_defined_op): Likewise. * valops.c (typecmp): Change parameter type from array pointer to array_view. Update header comment, and update body accordingly. (search_struct_method): Likewise. (value_struct_elt): Likewise. * value.h (value_struct_elt): Update declaration. gdb/testsuite/ChangeLog: PR gdb/27994 * gdb.cp/method-call-in-c.cc (struct foo_type): Add operator+=, change initial value of var member variable. (main): Make use of foo_type's operator+=. * gdb.cp/method-call-in-c.exp: Test use of operator+=.
2021-06-25gdb: fix regression in evaluate_funcall for non C++ like casesAndrew Burgess1-3/+12
This regression, as it is exposed by the test added in this commit, first became noticable with this commit: commit d182f2797922a305fbd1ef6a483cc39a56b43e02 Date: Mon Mar 8 07:27:57 2021 -0700 Convert c-exp.y to use operations But, this commit only added converted the C expression parser to make use of code that was added in this commit: commit a00b7254fb614af557de7ae7cc0eb39a0ce0e408 Date: Mon Mar 8 07:27:57 2021 -0700 Implement function call operations And it was this second commit that actually introduced the bugs (there are two). In structop_base_operation::evaluate_funcall we build up an argument list in the vector vals. Later in this function the argument list might be passed to value_struct_elt. Prior to commit a00b7254fb614 the vals vector (or argvec as it used to be called) stored the value for the function callee in the argvec at index 0. This 'callee' value is what ends up being passed to evaluate_subexp_do_call, and represents the function to be called, the value contents are the address of the function, and the value type is the function signature. The remaining items held in the argvec were the values to pass to the function. For a non-static member function the `this' pointer would be at index 1 in the array. After commit a00b7254fb614 this callee value is now held in a separate variable, not the vals array. So, for non-static member functions, the `this' pointer is now at index 0, with any other arguments after that. What this means is that previous, when we called value_struct_elt we would pass the address of argvec[1] as this was the first argument. But now we should be passing the address of vals[0]. Unfortunately, we are still passing vals[1], effectively skipping the first argument. The second issue is that, prior to commit a00b7254fb614, the argvec array was NULL terminated. This is required as value_struct_elt calls search_struct_method, which calls typecmp, and typecmp requires that the array have a NULL at the end. After commit a00b7254fb614 this NULL has been lost, and we are therefore violating the API requirements of typecmp. This commit fixes both of these regressions. I also extended the header comments on search_struct_method and value_struct_elt to make it clearer that the array required a NULL marker at the end. You will notice in the test attached to this commit that I test calling a non-static member function, but not calling a static member function. The reason for this is that calling static member functions is currently broken due to a different bug. That will be fixed in a later patch in this series, at which time I'll add a test for calling a static member function. gdb/ChangeLog: PR gdb/27994 * eval.c (structop_base_operation::evaluate_funcall): Add a nullptr to the end of the args array, which should not be included in the argument array_view. Pass all the arguments through to value_struct_elt. * valops.c (search_struct_method): Update header comment. (value_struct_elt): Likewise. gdb/testsuite/ChangeLog: PR gdb/27994 * gdb.cp/method-call-in-c.cc: New file. * gdb.cp/method-call-in-c.exp: New file.
2021-06-03gdb: fix eval.c assert during inferior exit eventMagne Hov1-1/+1
Evaluating expressions from within an inferior exit event handler can cause a crash: echo "int main() { return 0; }" > repro.c gcc -g repro.c -o repro ./gdb -q --ex "set language c++" --ex "python gdb.events.exited.connect(lambda _: gdb.execute('set \$_a=0'))" --ex "run" repro Reading symbols from repro... Starting program: /home/mhov/repos/binutils-gdb-master/install-bad/bin/repro [Inferior 1 (process 1974779) exited normally] ../../gdb/thread.c:72: internal-error: thread_info* inferior_thread(): Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Backtrace 0 in internal_error of ../../gdbsupport/errors.cc:51 1 in inferior_thread of ../../gdb/thread.c:72 2 in expression::evaluate of ../../gdb/eval.c:98 3 in evaluate_expression of ../../gdb/eval.c:115 4 in set_command of ../../gdb/printcmd.c:1502 5 in do_const_cfunc of ../../gdb/cli/cli-decode.c:101 6 in cmd_func of ../../gdb/cli/cli-decode.c:2181 7 in execute_command of ../../gdb/top.c:670 ... 22 in python_inferior_exit of ../../gdb/python/py-inferior.c:182 In `expression::evaluate (...)' there is a call to `inferior_thread ()' that is guarded by `target_has_execution ()': struct value * expression::evaluate (struct type *expect_type, enum noside noside) { gdb::optional<enable_thread_stack_temporaries> stack_temporaries; if (target_has_execution () && language_defn->la_language == language_cplus && !thread_stack_temporaries_enabled_p (inferior_thread ())) stack_temporaries.emplace (inferior_thread ()); The `target_has_execution ()' guard maps onto `inf->pid' and the `inferior_thread ()' call assumes that `current_thread_' is set to something meaningful: struct thread_info* inferior_thread (void) { gdb_assert (current_thread_ != nullptr); return current_thread_; } In other words, it is assumed that if `inf->pid' is set then `current_thread_' must also be set. This does not hold at the point where inferior exit observers are notified: - `generic_mourn_inferior (...)' - `switch_to_no_thread ()' - `current_thread_ = nullptr;' - `exit_inferior (...)' - `gdb::observers::inferior_exit.notify (...)' - `inf->pid = 0' The inferior exit notification means that a Python handler can get a chance to run while `current_thread' has been cleared and the `inf->pid' has not been cleared. Since the Python handler can call any GDB command with `gdb.execute(...)' (in my case `gdb.execute("set $_a=0")' we can end up evaluating expressions and asserting in `evaluate_subexp (...)'. This patch adds a test in `evaluate_subexp (...)' to check the global `inferior_ptid' which is reset at the same time as `current_thread_'. Checking `inferior_ptid' at the same time as `target_has_execution ()' seems to be a common pattern: $ git grep -n -e inferior_ptid --and -e target_has_execution gdb/breakpoint.c:2998: && (inferior_ptid == null_ptid || !target_has_execution ())) gdb/breakpoint.c:3054: && (inferior_ptid == null_ptid || !target_has_execution ())) gdb/breakpoint.c:4587: if (inferior_ptid == null_ptid || !target_has_execution ()) gdb/infcmd.c:360: if (inferior_ptid != null_ptid && target_has_execution ()) gdb/infcmd.c:2380: /* FIXME: This should not really be inferior_ptid (or target_has_execution). gdb/infrun.c:3438: if (!target_has_execution () || inferior_ptid == null_ptid) gdb/remote.c:11961: if (!target_has_execution () || inferior_ptid == null_ptid) gdb/solib.c:725: if (target_has_execution () && inferior_ptid != null_ptid) The testsuite has been run on 5.4.0-59-generic x86_64 GNU/Linux: - Ubuntu 20.04.1 LTS - gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 - DejaGnu version 1.6.2 - Expect version 5.45.4 - Tcl version 8.6 - Native configuration: x86_64-pc-linux-gnu - Target: unix Results show a few XFAIL in gdb.threads/attach-many-short-lived-threads.exp. The existing py-events.exp tests are skipped for native-gdbserver and fail for native-extended-gdbserver, but the new tests pass with native-extended-gdbserver when run without the existing tests. gdb/ChangeLog: 2021-06-03 Magne Hov <mhov@undo.io> PR python/27841 * eval.c (expression::evaluate): Check inferior_ptid. gdb/testsuite/ChangeLog: 2021-06-03 Magne Hov <mhov@undo.io> PR python/27841 * gdb.python/py-events.exp: Extend inferior exit tests. * gdb.python/py-events.py: Print inferior exit PID.
2021-04-15Use block_symbol in var_value_operationTom Tromey1-11/+13
I noticed that var_value_operation takes a block and a symbol, and most callers destructure a block_symbol to pass in. It seems better for this class to simply hold a block_symbol instead. Tested on x86-64 Fedora 32. gdb/ChangeLog 2021-04-15 Tom Tromey <tromey@adacore.com> * rust-exp.y (rust_parser::convert_ast_to_expression): Update. * parse.c (parser_state::push_symbol, parser_state::push_dollar): Update. * p-exp.y (variable): Update. * m2-exp.y (variable): Update. * go-exp.y (variable): Update. * expprint.c (dump_for_expression): New overload. * expop.h (check_objfile): New overload. (check_constant): New overload. (class var_value_operation): Use block_symbol. <get_symbol>: Rewrite. * eval.c (var_value_operation::evaluate) (var_value_operation::evaluate_funcall) (var_value_operation::evaluate_for_address) (var_value_operation::evaluate_for_address) (var_value_operation::evaluate_with_coercion) (var_value_operation::evaluate_for_sizeof) (var_value_operation::evaluate_for_cast): Update. * d-exp.y (PrimaryExpression): Update. * c-exp.y (variable): Update. * ax-gdb.c (var_value_operation::do_generate_ax): Update. * ada-lang.c (ada_var_value_operation::evaluate_for_cast) (ada_var_value_operation::evaluate) (ada_var_value_operation::resolve) (ada_funcall_operation::resolve): Update. * ada-exp.y (write_var_from_sym, write_object_renaming) (write_ambiguous_var, write_var_or_type, write_name_assoc) (maybe_overload): Update. * ada-exp.h (class ada_var_value_operation) <get_block>: Rewrite.
2021-03-24gdb: remove current_top_target functionSimon Marchi1-2/+3
The current_top_target function is a hidden dependency on the current inferior. Since I'd like to slowly move towards reducing our dependency on the global current state, remove this function and make callers use current_inferior ()->top_target () There is no expected change in behavior, but this one step towards making those callers use the inferior from their context, rather than refer to the global current inferior. gdb/ChangeLog: * target.h (current_top_target): Remove, make callers use the current inferior instead. * target.c (current_top_target): Remove. Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
2021-03-09Fix function call regression in new evaluatorTom Tromey1-1/+9
The internal AdaCore test suite revealed a bug in the new evaluator. A hunk of evaluate_funcall was not correctly transcribed. This was not caught in my original testing because the feature in question was apparently not tested in gdb. This patch fixes the oversight. The idea here is that ordinary function calls should use the function's formal parameter types as the expected types of subexpressions. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2021-03-09 Tom Tromey <tromey@adacore.com> * eval.c (operation::evaluate_funcall): Use function formal parameter types when evaluating. gdb/testsuite/ChangeLog 2021-03-09 Tom Tromey <tromey@adacore.com> * gdb.base/cast-call.exp: New file. * gdb.base/cast-call.c: New file.
2021-03-08Use bound_minimal_symbol in var_msym_value_operationTom Tromey1-14/+11
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.
2021-03-08Remove EVAL_SKIPTom Tromey1-94/+9
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.
2021-03-08Merge namespace scopes in eval.cTom Tromey1-10/+0
The big deletion patch left some identical namespace scopes sitting next to one another. This patch removes the redundant "namespace expr"s. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * eval.c: Merge "namespace" scopes.
2021-03-08Remove union exp_elementTom Tromey1-1617/+7
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.
2021-03-08Add an expr::operation_up to struct expressionTom Tromey1-5/+25
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.
2021-03-08Implement function call operationsTom Tromey1-0/+280
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.
2021-03-08Introduce array_operationTom Tromey1-0/+200
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.
2021-03-08Introduce class adl_func_operationTom Tromey1-0/+23
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.
2021-03-08Implement the "&&" and "||" operatorsTom Tromey1-0/+63
This implements the "&&" and "||" operators. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class logical_and_operation) (class logical_or_operation): New. * eval.c (logical_and_operation::evaluate) (logical_or_operation::evaluate): New methods. * ax-gdb.c (logical_and_operation::do_generate_ax) (logical_or_operation::do_generate_ax): New methods.
2021-03-08Introduce multi_subscript_operationTom Tromey1-0/+13
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.
2021-03-08Introduce objc_msgcall_operationTom Tromey1-0/+39
This adds class objc_msgcall_operation, which implements OP_OBJC_MSGCALL. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * eval.c (objc_msgcall_operation::evaluate): New method. * c-exp.h (class objc_msgcall_operation): New.
2021-03-08Introduce var_value_operationTom Tromey1-0/+112
This adds class var_value_operation, which implements OP_VAR_VALUE. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class var_value_operation): New. * eval.c (var_value_operation::evaluate) (var_value_operation::evaluate_for_address) (var_value_operation::evaluate_with_coercion) (var_value_operation::evaluate_for_sizeof) (var_value_operation::evaluate_for_cast): New methods. * ax-gdb.c (var_value_operation::do_generate_ax): New method.
2021-03-08Introduce assign_modify_operationTom Tromey1-1/+1
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.
2021-03-08Introduce type_instance_operationTom Tromey1-0/+18
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.
2021-03-08Implement UNOP_MEMVAL and UNOP_MEMVAL_TYPETom Tromey1-1/+36
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.
2021-03-08Introduce unop_alignof_operationTom Tromey1-1/+1
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.
2021-03-08Introduce type_operationTom Tromey1-1/+1
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.
2021-03-08Introduce unop_ind_operationTom Tromey1-5/+40
This adds class unop_ind_operation, which implements UNOP_IND. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class unop_ind_base_operation) (class unop_ind_operation): New. * eval.c (eval_op_ind): No longer static. Remove "op" parameter. (unop_ind_base_operation::evaluate_for_address) (unop_ind_base_operation::evaluate_for_sizeof): New method. * ax-gdb.c (gen_expr_unop) <case UNOP_IND>: New.
2021-03-08Implement unary increment and decrement operationsTom Tromey1-4/+4
This implements the unary increment and decrement operations, "++" and "--". gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (unop_incr_operation): New template. (preinc_operation, predec_operation, postinc_operation) (postdec_operation): New typedefs. * eval.c (eval_op_preinc, eval_op_predec, eval_op_postinc) (eval_op_postdec): No longer static.
2021-03-08Implement some unary operationsTom Tromey1-4/+4
This introduces a couple of new template classes and then uses them to implement some simple unary operations. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (unary_ftype): New typedef. (unop_operation, usual_ax_binop_operation): New templates. (unary_plus_operation, unary_neg_operation) (unary_complement_operation, unary_logical_not_operation): New typedefs. * eval.c (eval_op_plus, eval_op_neg, eval_op_complement) (eval_op_lognot): No longer static. * ax-gdb.c (gen_expr_unop): New function.
2021-03-08Introduce repeat_operationTom Tromey1-3/+3
This adds class repeat_operation, which implements BINOP_REPEAT. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class repeat_operation): New. * eval.c (eval_op_repeat): No longer static. Remove "op" parameter. (evaluate_subexp_standard): Update. * ax-gdb.c (repeat_operation::do_generate_ax): New method.
2021-03-08Implement binary comparison operationsTom Tromey1-6/+6
This implements the binary comparison operations via a template class. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class comparison_operation): New. (equal_operation, notequal_operation, less_operation) (gtr_operation, geq_operation, leq_operation): New typedefs. * eval.c (eval_op_equal, eval_op_notequal, eval_op_less) (eval_op_gtr, eval_op_geq, eval_op_leq): No longer static.
2021-03-08Introduce subscript_operationTom Tromey1-1/+34
This adds class subscript_operation, which implements BINOP_SUBSCRIPT. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class subscript_operation): New. * eval.c (eval_op_subscript): No longer static.
2021-03-08Introduce binop_operationTom Tromey1-1/+1
This adds two new template classes, binop_operation and usual_ax_binop_operation, and then uses these to implement a number of binary operations that follow similar patterns. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class binop_operation, class usual_ax_binop_operation): New. (exp_operation, intdiv_operation, mod_operation, mul_operation) (div_operation, rem_operation, lsh_operation, rsh_operation) (bitwise_and_operation, bitwise_ior_operation) (bitwise_xor_operation): New typedefs. * eval.c (eval_op_binary): No longer static.
2021-03-08Introduce sub_operationTom Tromey1-5/+5
This adds class sub_operation, which implements BINOP_SUB. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class sub_operation): New. * eval.c (eval_op_sub): No longer static. Remove "op" parameter. (evaluate_subexp_standard): Update.
2021-03-08Introduce add_operationTom Tromey1-5/+5
This adds class add_operation, which implements BINOP_ADD. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class add_operation): New. * eval.c (eval_op_add): No longer static. Remove "op" parameter. (evaluate_subexp_standard): Update.
2021-03-08Introduce concat_operationTom Tromey1-6/+5
This adds class concat_operation, which implements BINOP_CONCAT. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class concat_operation): New. * eval.c (eval_op_concat): No longer static. Remove "op" parameter. (evaluate_subexp_standard): Update.
2021-03-08Introduce structop_member_operation and structop_mptr_operationTom Tromey1-1/+1
This adds class structop_member_operation and structop_mptr_operation, which implement STRUCTOP_MEMBER and STRUCTOP_MPTR. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * expop.h (class structop_member_operation) (class structop_mptr_operation): New. * eval.c (eval_op_member): No longer static.