aboutsummaryrefslogtreecommitdiff
path: root/gdb/findvar.c
AgeCommit message (Collapse)AuthorFilesLines
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
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi1-4/+4
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-20Replace symbol_arch with symbol::archTom Tromey1-1/+1
This turns symbol_arch into a method on symbol.
2022-04-20Replace symbol_objfile with symbol::objfileTom Tromey1-5/+5
This turns symbol_objfile into a method on symbol.
2022-04-11gdb: remove symbol value macrosSimon Marchi1-14/+13
Remove all macros related to getting and setting some symbol value: #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue #define SYMBOL_VALUE_ADDRESS(symbol) \ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ #define BMSYMBOL_VALUE_ADDRESS(symbol) \ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block Replace them with equivalent methods on the appropriate objects. Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
2022-02-11Add initializers to bound_minimal_symbolTom Tromey1-2/+1
This adds initializers to bound_minimal_symbol, allowing for the removal of some calls to memset.
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-1/+1
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-3/+3
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
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-12-03gdb: make extract_integer take an array_viewSimon Marchi1-18/+17
I think it would make sense for extract_integer, extract_signed_integer and extract_unsigned_integer to take an array_view. This way, when we extract an integer, we can validate that we don't overflow the buffer passed by the caller (e.g. ask to extract a 4-byte integer but pass a 2-byte buffer). - Change extract_integer to take an array_view - Add overloads of extract_signed_integer and extract_unsigned_integer that take array_views. Keep the existing versions so we don't need to change all callers, but make them call the array_view versions. This shortens some places like: result = extract_unsigned_integer (value_contents (result_val).data (), TYPE_LENGTH (value_type (result_val)), byte_order); into result = extract_unsigned_integer (value_contents (result_val), byte_order); value_contents returns an array view that is of length `TYPE_LENGTH (value_type (result_val))` already, so the length is implicitly communicated through the array view. Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95
2021-11-18gdbsupport: make gdb_assert_not_reached accept a format stringSimon Marchi1-2/+2
Change gdb_assert_not_reached to accept a format string plus corresponding arguments. This allows giving more precise messages. Because the format string passed by the caller is prepended with a "%s:" to add the function name, the callers can no longer pass a translated string (`_(...)`). Make the gdb_assert_not_reached include the _(), just like the gdb_assert_fail macro just above. Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
generated by cgit v1.1 at 2024-09-02 08:09:45 +0000