aboutsummaryrefslogtreecommitdiff
path: root/gdb/eval.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-06[gdb] Fix common misspellingsTom de Vries1-1/+1
Fix the following common misspellings: ... accidently -> accidentally additonal -> additional addresing -> addressing adress -> address agaisnt -> against albiet -> albeit arbitary -> arbitrary artifical -> artificial auxillary -> auxiliary auxilliary -> auxiliary bcak -> back begining -> beginning cannonical -> canonical compatiblity -> compatibility completetion -> completion diferent -> different emited -> emitted emiting -> emitting emmitted -> emitted everytime -> every time excercise -> exercise existance -> existence fucntion -> function funtion -> function guarentee -> guarantee htis -> this immediatly -> immediately layed -> laid noone -> no one occurances -> occurrences occured -> occurred originaly -> originally preceeded -> preceded preceeds -> precedes propogate -> propagate publically -> publicly refering -> referring substract -> subtract substracting -> subtracting substraction -> subtraction taht -> that targetting -> targeting teh -> the thier -> their thru -> through transfered -> transferred transfering -> transferring upto -> up to vincinity -> vicinity whcih -> which whereever -> wherever wierd -> weird withing -> within writen -> written wtih -> with doesnt -> doesn't ... Tested on x86_64-linux.
2024-10-01Introduce and use operation::type_pTom Tromey1-4/+7
There's currently code in gdb that checks if an expression evaluates to a type. In some spots this is done by comparing the opcode against OP_TYPE, but other spots more correctly also compare with OP_TYPEOF and OP_DECLTYPE. This patch cleans up this area, replacing opcode-checking with a new method on 'operation'. Generally, checking the opcode should be considered deprecated, although it's unfortunately difficult to get rid of opcodes entirely. I also took advantage of this change to turn eval_op_type into a method, removing a bit of indirection. Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-08-12gdb: add program_space parameter to lookup_minimal_symbolSimon Marchi1-1/+2
>From what I can see, lookup_minimal_symbol doesn't have any dependencies on the global current state other than the single reference to current_program_space. Add a program_space parameter and make that current_program_space reference bubble up one level. Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-08-12gdb: make lookup_minimal_symbol objf and sfile parameters optionalSimon Marchi1-1/+1
Most calls to lookup_minimal_symbol don't pass a value for sfile and objf. Make these parameters optional (have a default value of nullptr). And since passing a value to `objf` is much more common than passing a value to `sfile`, swap the order so `objf` comes first, to avoid having to pass a nullptr value to `sfile` when wanting to pass a value to `objf`. Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-07-24[gdb/exp] Allow internal function to indicate return typeTom de Vries1-6/+3
Currently an internal function handler has this prototype: ... struct value *handler (struct gdbarch *gdbarch, const struct language_defn *language, void *cookie, int argc, struct value **argv); ... Also allow an internal function with a handler with an additional "enum noside noside" parameter: ... struct value *handler (struct gdbarch *gdbarch, const struct language_defn *language, void *cookie, int argc, struct value **argv, enum noside noside); ... In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's expected to return some value with the correct return type. At least, provided it can do so without side effects, otherwise it should throw an error. No functional changes. Tested on x86_64-linux and aarch64-linux. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-06-12Allow calling of user-defined function call operatorsHannes Domani1-3/+31
Currently it's not possible to call user-defined function call operators, at least not without specifying operator() directly: ``` (gdb) l 1 1 struct S { 2 int operator() (int x) { return x + 5; } 3 }; 4 5 int main () { 6 S s; 7 8 return s(23); 9 } (gdb) p s(10) Invalid data type for function to be called. (gdb) p s.operator()(10) $1 = 15 ``` This now looks if an user-defined call operator is available when trying to 'call' a struct value, and calls it instead, making this possible: ``` (gdb) p s(10) $1 = 15 ``` The change in operation::evaluate_funcall is to make sure the type fields are only used for function types, only they use them as the argument types. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213 Approved-By: Tom Tromey <tom@tromey.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-26Remove two unnecessary castsTom Tromey1-1/+1
I noticed a spot in ada-lang.c where the return value of value_as_address was cast to CORE_ADDR -- a no-op cast. I searched and found another. This patch fixes both.
2024-02-05Handling of arrays with optimized-out boundsTom Tromey1-1/+1
In Ada, sometimes the compiler must emit array bounds by referencing an artificial variable that's created for this purpose. However, with optimization enabled, these variables can be optimized away. Currently this can result in displays like: (gdb) print mumble $1 = (warning: unable to get bounds of array, assuming null array ) This patch changes this to report that the array is optimized-out, instead, which is closer to the truth, and more generally useful. For example, Python pretty-printers can now recognize this situation. In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT enumerator and changed one place to use it. Reusing the "unknown" state wouldn't work properly, because in C it is normal for array bounds to be unknown.
2024-02-02gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointersNils-Christian Kempke1-0/+7
For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like <2><17d>: Abbrev Number: 22 (DW_TAG_variable) <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr <184> DW_AT_type : <0x214> ... <1><219>: Abbrev Number: 27 (DW_TAG_array_type) <21a> DW_AT_type : <0x10e> <216> DW_AT_associated : ... The 'pointer property' in Fortran is implicitly modeled by adding a DW_AT_associated to the type of the variable (see also the DW_AT_associated description in DWARF 5). A Fortran pointer is more than an address and thus different from a C pointer. It is a self contained type having additional fields such as, e.g., the rank of its underlying array. This motivates the intended DWARF modeling of Fortran pointers via the DW_AT_associated attribute. This patch adds support for the sizeof intrinsic by simply dereferencing pointer types when encountered during a sizeof evaluation. The patch also adds a test for the sizeof intrinsic which was not tested before. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-2/+3
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-19gdb: remove SYMBOL_*_OPS macrosSimon Marchi1-3/+4
Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in favor of methods on struct symbol. More changes could be done here to improve the design and make things safer, but I just wanted to do a straightforward change to remove the macros for now. Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-12-14gdb: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi1-1/+2
Some functions related to the handling of registers in frames accept "this frame", for which we want to read or write the register values, while other functions accept "the next frame", which is the frame next to that. The later is needed because we sometimes need to read register values for a frame that does not exist yet (usually when trying to unwind that frame-to-be). value_of_register and value_of_register_lazy both take "this frame", even if what they ultimately want internally is "the next frame". This is annoying if you are in a spot that currently has "the next frame" and need to call one of these functions (which happens later in this series). You need to get the previous frame only for those functions to get the next frame again. This is more manipulations, more chances of mistake. I propose to change these functions (and a few more functions in the subsequent patches) to operate on "the next frame". Things become a bit less awkward when all these functions agree on which frame they take. So, in this patch, change value_of_register_lazy and value_of_register to take "the next frame" instead of "this frame". This adds a lot of get_next_frame_sentinel_okay, but if we convert the user registers API to also use "the next frame" instead of "this frame", it will get simple again. Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-1/+1
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Remove uses of gdb::to_string (const std::string_view &)Lancelot Six1-1/+0
This patch removes all uses of to_string(const std::string_view&) and use the std::string ctor or implicit conversion from std::string_view to std::string instead. A later patch will remove this gdb::to_string while removing gdbsupport/gdb_string_view.h. Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-0/+1
Given that GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automatically: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> One things which got brought up during review is that gdb::stging_view does support being built from "nullptr" while std::sting_view does not. Two places are manually adjusted to account for this difference: gdb/tui/tui-io.c:tui_getc_1 and gdbsupport/format.h:format_piece::format_piece. The above automatic change transformed "gdb::to_string (const gdb::string_view &)" into "gdb::to_string (const std::string_view &)". The various direct users of this function are now explicitly including "gdbsupport/gdb_string_view.h". A later patch will remove the users of gdb::to_string. The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-1/+1
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-31gdb: remove TYPE_FIELD_BITSIZESimon Marchi1-1/+1
Replace with type::field + field::bitsize. Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31Remove eval_op_ternopTom Tromey1-12/+17
eval_op_ternop is only used by the implementation of ternop_slice_operation. While working on another series, it was convenient for me to merge this function into its only caller. Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2023-08-29More renames in array_operation::evaluateTom Tromey1-4/+3
array_operation::evaluate has variables named "tem2" and "tem3". This patch replaces one with a better name, and entirely removes the other. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Remove "highbound" parameter from value_arrayTom Tromey1-1/+1
value_array requires the passed-in bounds to match the length of the array_view it is given. This patch removes the redundant "highbound" parameter. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Remove another redundant variable from array_operation::evaluateTom Tromey1-8/+4
This removes yet another redundant variable from array_operation::evaluate -- only one index is needed. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Remove redundant variable from array_operation::evaluateTom Tromey1-3/+2
In array_operation::evaluate, 'idx' and 'tem' are redundant in one branch. This patch merges them, using the clearer name. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Hoist array bounds check in array_operation::evaluateTom Tromey1-3/+2
This hoists the array bounds check in array_operation::evaluate to before the loop. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Declare 'tem' in loop header in array_operation::evaluateTom Tromey1-5/+4
This changes array_operation::evaluate to declare the 'tem' variable in the loop header, rather than at the top of the function. This is cleaner and easier to reason about. I also changed 'nargs' to be 'const'. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-29Use gdb::array_view for value_arrayTom Tromey1-1/+1
This changes value_array to accept an array view. I also replaced an alloca with a std::vector in array_operation::evaluate. This function can work on any size of array, so it seems bad to use alloca. Reviewed-by: John Baldwin <jhb@FreeBSD.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-23Add flags to parse_and_evalTom Tromey1-2/+2
This adds a flags parameter to parse_and_eval.
2023-05-23Introduce and use parser flagsTom Tromey1-1/+2
This patch adds a new parser_flags type and changes the parser APIs to use it rather than a collection of 'int' and 'bool'. More flags will be added in subsquent patches.
2023-05-01Remove evaluate_typeTom Tromey1-9/+0
Like evaluate_expression, evaluate_type is also just a simple wrapper. Removing it makes the code a little nicer.
2023-05-01Remove evaluate_expressionTom Tromey1-12/+4
evaluate_expression is just a little wrapper for a method on expression. Removing it also removes a lot of ugly (IMO) calls to get().
2023-05-01Replace field_is_static with a methodTom Tromey1-1/+1
This changes field_is_static to be a method on struct field, and updates all the callers. Most of this patch was written by script. Regression tested on x86-64 Fedora 36.
2023-03-27Simplify binop_promoteTom Tromey1-36/+19
binop_promote currently only handles integer sizes up to builtin_long_long. However, this may not handle 128-bit types. Simplify this code, unify the C and non-C (but not OpenCL, as I don't know how to test this) cases, and handle 128-bit integers as well. This still doesn't exactly follow C or C++ rules. This could be implemented, but if so, I think it makes more sense as a C-specific expression node.
2023-02-13Remove deprecated_lval_hackTom Tromey1-6/+6
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing all uses with a call to value::lval. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Introduce set_lval method on valueTom Tromey1-2/+2
This introduces the set_lval method on value, one step toward removing deprecated_lval_hack. Ultimately I think the goal should be for some of these set_* methods to be replaced with constructors; but I haven't done this, as the series is already too long. Other 'deprecated' methods can probably be handled the same way. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn various value copying-related functions into methodsTom Tromey1-1/+1
This patch turns a grab bag of value functions to methods of value. These are done together because their implementations are interrelated. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some xmethod functions into methodsTom Tromey1-2/+2
This turns value_from_xmethod, result_type_of_xmethod, and call_xmethod to be methods of value. value_from_xmethod is a static "constructor" now. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_non_lval and value_force_lval into methodsTom Tromey1-3/+3
This changes value_non_lval and value_force_lval to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey1-2/+2
This turns the remaining value_contents functions -- value_contents, value_contents_all, value_contents_for_printing, and value_contents_for_printing_const -- into methods of value. It also converts the static functions require_not_optimized_out and require_available to be private methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_fetch_lazy into a methodTom Tromey1-3/+3
This changes value_fetch_lazy to be a method of value. A few helper functions are converted as well, to avoid problems in later patches when the data members are all made private. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some value_contents functions into methodsTom Tromey1-5/+5
This turns value_contents_raw, value_contents_writeable, and value_contents_all_raw into methods on value. The remaining functions will be changed later in the series; they were a bit trickier and so I didn't include them in this patch. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_zero into static "constructor"Tom Tromey1-22/+22
This turns value_zero into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_optimized_out_value into static "constructor"Tom Tromey1-1/+1
This turns allocate_optimized_out_value into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-8/+8
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_address and set_value_address functions into methodsTom Tromey1-3/+3
This changes the value_address and set_value_address functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_lazy and set_value_lazy functions into methodsTom Tromey1-3/+3
This changes the value_lazy and set_value_lazy functions to be methods of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some value offset functions into methodTom Tromey1-1/+1
This changes various offset-related functions to be methods of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn deprecated_set_value_type into a methodTom Tromey1-1/+1
This changes deprecated_set_value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey1-69/+69
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
generated by cgit v1.1 at 2024-12-14 00:21:01 +0000