aboutsummaryrefslogtreecommitdiff
path: root/gdb/findvar.c
AgeCommit message (Collapse)AuthorFilesLines
2025-01-15[gdb] Add gdbarch_dwarf2_reg_piece_offset hookTom de Vries1-0/+18
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and DW_OP_bit_piece are handled the same, but the standard tells us: - DW_OP_piece: if the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. - DW_OP_bit_piece: if the location is a register, the offset is from the least significant bit end of the register. Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the ABI-specific behaviour for DW_OP_piece. The default implementation of the hook is the behaviour of DW_OP_bit_piece, so there should not be any functional changes. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.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-2/+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-04-23gdb: move a bunch of quit-related things to event-top.{c,h}Simon Marchi1-0/+1
Move some declarations related to the "quit" machinery from defs.h to event-top.h. Most of the definitions associated to these declarations are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, that are defined in utils.c. For consistency, move these two definitions to event-top.c. Include "event-top.h" in many files that use these things. Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-238/+1
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: remove extract_long_unsigned_integerSimon Marchi1-53/+0
It is unused. Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74 Approved-By: John Baldwin <jhb@FreeBSD.org>
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-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi1-11/+13
We currently pass frames to function by value, as `frame_info_ptr`. This is somewhat expensive: - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass by value - the constructors and destructor link/unlink the object in the global `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so it's not so bad: it's just assigning a few points, there's no memory allocation as if it was `std::list`, but still it's useless to do that over and over. As suggested by Tom Tromey, change many function signatures to accept `const frame_info_ptr &` instead of `frame_info_ptr`. Some functions reassign their `frame_info_ptr` parameter, like: void the_func (frame_info_ptr frame) { for (; frame != nullptr; frame = get_prev_frame (frame)) { ... } } I wondered what to do about them, do I leave them as-is or change them (and need to introduce a separate local variable that can be re-assigned). I opted for the later for consistency. It might not be clear why some functions take `const frame_info_ptr &` while others take `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because it did re-assign its parameter, I doubt that we would think to change it to `const frame_info_ptr &` should the implementation change such that it doesn't need to take `frame_info_ptr` anymore. It seems better to have a simple rule and apply it everywhere. Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-01-19gdb: remove SYMBOL_*_OPS macrosSimon Marchi1-6/+7
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-19gdb: remove unnecessary NULL checks for return value of value_from_registerSimon Marchi1-20/+3
value_from_register can't return nullptr, remove some NULL checks. Change-Id: Ia6b32b8f86e593c535e3678a89dffe5544eb7ab0 Approved-By: Tom Tromey <tom@tromey.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-24gdb: make value::allocate_register_lazy store id of next non-inline frameSimon Marchi1-16/+3
Some spots loop on the frame chain to find the first next non-inline frame, and pass that as the "next frame" to value::allocate_register_lazy / value::allocate_register. This is necessary if the value is used in the process of computing the id of "this frame". If the frame next to "this frame" is inlined into "this frame", then you that next frame won't have a computed id yet. You have to go past that to find the next non-inline frame, which will have a computed id. In other cases, it's fine to store the id of an inline frame as the "next frame id" in a register struct value. When trying to unwind a register from it, it will just call inline_frame_prev_register, which will forward the request to the next next frame, until we hit the next physical frame. I think it would make things simpler to just never store the id of an inline frame as the next frame id of register struct values, and go with the first next non-inline frame directly. This way, we don't have to wonder which code paths have to skip inline frames when creating register values and which don't. So, change value::allocate_register_lazy to do that work, and remove the loops for the callers that did it. Change-Id: Ic88115dac49dc14e3053c95f92050062b24b7310
2023-12-24gdb: remove VALUE_REGNUM, add value::regnumSimon Marchi1-1/+1
Remove VALUE_REGNUM, replace it with a method on struct value. Set `m_location.reg.regnum` directly from value::allocate_register_lazy, which is fine because allocate_register_lazy is a static creation function for struct value. Change-Id: Id632502357da971617d9dce1e2eab9b56dbcf52d
2023-12-24gdb: remove VALUE_NEXT_FRAME_ID, add value::next_frame_idSimon Marchi1-1/+1
Remove VALUE_NEXT_FRAME_ID, replace it with a method on struct value. Set `m_location.reg.next_frame_id` directly from value::allocate_register_lazy, which is fine because allocate_register_lazy is a static creation function for struct value. Change-Id: Ic9f0f239c166a88dccfee836f9f51871e67548e6
2023-12-24gdb: implement address_from_register using value_from_registerSimon Marchi1-37/+4
As explained in the comment removed by the previous commit "gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register", address_from_register copies some implementation bits from value_from_register: /* This routine may be called during early unwinding, at a time where the ID of FRAME is not yet known. Calling value_from_register would therefore abort in get_frame_id. However, since we only need a temporary value that is never used as lvalue, we actually do not really need to set its VALUE_NEXT_FRAME_ID. Therefore, we re-implement the core of value_from_register, but use the null_frame_id. */ This is no longer relevant, since we now create a value with a valid next frame id, so change address_from_register to use value_from_register. Change-Id: I189bd96f28735ed9f47750ffd73764c459ec6f43
2023-12-24gdb: remove read_frame_register_value's frame parameterSimon Marchi1-10/+13
By now, all register struct values should have a valid next frame id (assuming they are created using value::allocate_register or value::allocate_register_lazy), so there should be no need to pass a frame alongside the value to read_frame_register_value. Remove the frame parameter and adjust read_frame_register_value accordingly. While at it, make read_frame_register_value static, it's only used in findvar.c. Change-Id: I118959ef8c628499297c67810916e8ba9934bfac
2023-12-24gdb: add type parameter to value::allocate_register and add ↵Simon Marchi1-18/+6
value::allocate_register_lazy Some places that create register struct values don't use register_type to obtain the value type. This prevents them from using the current version of value::allocate_register. One spot (value_of_register_lazy) also creates a lazy register value. Add a value::allocate_register_lazy method. Add some type parameters to value::allocate_register and value::allocate_register_lazy, to let the caller specify the type to use for the value. The parameters default to nullptr, in which case we use register_type to obtain the type. Change-Id: I640ec0a5a0f4a55eba12d515dbfd25933229f8ec
2023-12-24gdb: pass non-nullptr frame to gdbarch_value_from_register in ↵Simon Marchi1-14/+5
address_from_register address_from_register used to pass null_frame_id to gdbarch_value_from_register as "this frame"'s id, because it's possible for it to be called during unwind, when "this frame"'s id is not yet known. This create an oddity where those register struct values are created without a valid next frame id. I would much prefer for things to be consistent and have all register struct values to have a valid next frame id. Since gdbarch_value_from_register takes a frame_info_ptr now, rather than a frame_id, we can pass down "this frame", even if it doesn't have a valid id. gdbarch_value_from_register implementations can obtain the next frame from it. However, it's possible for the "this frame"'s next frame to be an inline frame, inlined in "this frame", in which case that next frame's id is also not known. So, loop until we get to the next non-inline frame (which is actually the frame where registers for "this frame" are unwound from). This is the same thing that we do in value_of_register_lazy, for the same reason. A later patch will factor out this "while next frame is inline" loop to apply it to all register struct values, so this is somewhat temporary. Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
2023-12-24gdb: pass frame_info_ptr to gdbarch_value_from_registerSimon Marchi1-14/+10
Pass a frame_info_ptr rather than a frame_id. This avoids having to do a frame lookup on the callee side, when we can just pass the frame down directly. I think this fixes a bug in rs6000-tdep.c where the id of the wrong frame was set to `VALUE_NEXT_FRAME_ID (v)`. Change-Id: I77039bc87ea8fc5262f16d0e1446515efa21c565
2023-12-14gdb: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi1-22/+12
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-12-14gdb: make store_integer take an array_viewSimon Marchi1-9/+7
Change store_integer, store_signed_integer and store_unsigned_integer to accept an array_view. Add some backwards compatibility overloads to avoid changing all callers at once. Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-08Fix dynamic type resolution for LOC_CONST and LOC_CONST_BYTES symbolsTom Tromey1-4/+15
PR rust/31005 points out that dynamic type resolution of a LOC_CONST or LOC_CONST_BYTES symbol will fail, leading to output like: from_index=<error reading variable: Cannot access memory at address 0x0> This patch fixes the problem by using the constant value or bytes when performing type resolution. Thanks to tpzker@thepuzzlemaker.info for a first version of this patch. I also tested this on a big-endian PPC system (cfarm203). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
2023-11-14Move follow_static_link to frame.cTom Tromey1-53/+6
This moves the follow_static_link function to frame.c and exports it for use elsewhere. The API is changed slightly to make it more generically useful.
2023-11-14Add two convenience methods to blockTom Tromey1-3/+2
This adds a couple of convenience methods, block::is_static_block and block::is_global_block.
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-03-28Rename "raw" to "unrelocated"Tom Tromey1-1/+1
Per an earlier discussion, this patch renames the existing "raw" APIs to use the word "unrelocated" instead.
2023-03-28Use unrelocated_addr in minimal symbolsTom Tromey1-2/+2
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-02-19Convert block_static_link to methodTom Tromey1-1/+1
This converts block_static_link to be a method. This was mostly written by script.
2023-02-19Convert block_static_block and block_global_block to methodsTom Tromey1-3/+3
This converts block_static_block and block_global_block to be methods. This was mostly written by script. It was simpler to convert them at the same time because they're often used near each other.
2023-02-19Convert block_inlined_p to methodTom Tromey1-1/+1
This converts block_inlined_p to be a method. This was mostly written by script.
2023-02-13Remove deprecated_lval_hackTom Tromey1-1/+1
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-6/+6
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 many optimized-out value functions into methodsTom Tromey1-3/+3
This turns many functions that are related to optimized-out or availability-checking to be methods of value. The static function value_entirely_covered_by_range_vector is also converted to be a private method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_fetch_lazy into a methodTom Tromey1-1/+1
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-3/+3
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 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-4/+4
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value_lazy into a static "constructor"Tom Tromey1-1/+1
This changes allocate_value_lazy to be a static "constructor" of struct value. I considered trying to change value to use ordinary new/delete, but it seems to me that due to reference counting, we may someday want to change these static constructors to return value_ref_ptr instead. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_offset into methodTom Tromey1-3/+3
This changes value_offset 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-2/+2
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>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-16gdb: fix crash when getting the value of a label symbolAndrew Burgess1-14/+26
When the source program contains a goto label, it turns out it's actually pretty hard for a user to find out more about that label. For example: (gdb) p some_label No symbol "some_label" in current context. (gdb) disassemble some_label No symbol "some_label" in current context. (gdb) x/10i some_label No symbol "some_label" in current context. (gdb) break some_label Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35. In all cases, some_label is a goto label within the current frame. Only placing a breakpoint on the label worked. This all seems a little strange to me, it feels like asking about a goto label would not be an unreasonable thing for a user to do. This commit doesn't fix any of the above issues, I mention them just to provide a little context for why the following issue has probably not been seen before. It turns out there is one way a user can access the symbol for a goto label, through the Python API: python frame = gdb.selected_frame() python frame_pc = frame.pc() python block = gdb.current_progspace().block_for_pc(frame_pc) python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN) python print(str(symbol.value())) ../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed. The problem is that label symbols are created using the builtin_core_addr type, which is a pure integer type. When GDB tries to fetch the value of a label symbol then we end up in findvar.c, in the function language_defn::read_var_value, in the LOC_LABEL case. From here store_typed_address is called to store the address of the label into a value object with builtin_core_addr type. The problem is that store_typed_address requires that the destination type be a pointer or reference, which the builtin_core_addr type is not. Now it's not clear what type a goto label address should have, but GCC has an extension that allows users to take the address of a goto label (using &&), in that case the result is of type 'void *'. I propose that when we convert the CORE_ADDR value to a GDB value object, we use builtin_func_ptr type instead of builtin_core_addr, this means the result will be of type 'void (*) ()'. The benefit of this approach is that when gdbarch_address_to_pointer is called the target type will be correctly identified as a pointer to code, which should mean any architecture specific adjustments are done correctly. We can then cast the new value to 'void *' type with a call to value_cast_pointer, this should not change the values bit representation, but will just update the type. After this asking for the value of a label symbol works just fine: (gdb) python print(str(symbol.value())) 0x401135 <main+35> And the type is maybe what we'd expect: (gdb) python print(str(symbol.value().type)) void *
2022-12-15gdb: use gdb_assert not internal_errorAndrew Burgess1-8/+2
Spotted a couple of places in findvar.c where we use: if ( ! CONDITION ) internal_error ("..."); this commit changes these to be: gdb_assert ( CONDITION ); which I think is better. Unless we happen to hit the internal_error calls (which was bad) there should be no user visible changes after this commit.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-4/+2
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-13/+13
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-10/+10
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-05-05gdb: use gdb::function_view for ↵Simon Marchi1-41/+14
gdbarch_iterate_over_objfiles_in_search_order callback A rather straightforward patch to change an instance of callback + void pointer to gdb::function_view, allowing pasing lambdas that capture, and eliminating the need for the untyped pointer. Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi1-2/+2
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi1-1/+1
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
generated by cgit v1.1 at 2025-03-28 23:32:39 +0000