aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2/expr.c
AgeCommit message (Collapse)AuthorFilesLines
2023-05-11Do not print <synthetic pointer> when piece is optimized outTom Tromey1-6/+13
A user reported a bug where printing a certain array of integer types would result in the nonsensical: (gdb) p l_126 $1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>} I tracked this down to some issues in the DWARF expression code. First, check_pieced_synthetic_pointer did not account for the situation where a location expression does not describe all the bits of a value -- in this case it returned true, meaning there is a synthetic pointer, but in fact these bits are optimized out. (It turns out this incorrect output had already been erroneously tested for as well.) Next, rw_pieced_value did not mark these bits as optimized-out, either. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296
2023-03-29Use the correct frame when evaluating a dynamic propertyTom Tromey1-2/+2
The test case in this patch shows an unusual situation: an Ada array has a dynamic bound, but the bound comes from a frame that's referred to by the static link. This frame is correctly found when evaluating the array variable itself, but is lost when evaluating the array's bounds. This patch fixes the problem by passing this frame through to value_at_lazy in the DWARF expression evaluator.
2023-03-18Unify arch_integer_type and init_integer_typeTom Tromey1-3/+6
This unifies arch_integer_type and init_integer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-19Convert block_linkage_function to methodTom Tromey1-1/+1
This converts block_linkage_function to be a method. This was mostly written by script.
2023-02-15Have value::bits_synthetic_pointer return boolTom Tromey1-3/+3
This changes value::bits_synthetic_pointer to return bool and fixes up some fallout from this. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_stack to boolTom Tromey1-1/+1
This changes value::m_stack to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-15Change value::m_initialized to boolTom Tromey1-2/+2
This changes value::m_initialized to be a bool and updates the various uses. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-02-13Turn various value copying-related functions into methodsTom Tromey1-2/+2
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-9/+9
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 remaining value_contents functions into methodsTom Tromey1-6/+6
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_incref and value_decref into methodsTom Tromey1-2/+2
This changes value_incref and value_decref to be methods of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_bits_synthetic_pointer into a methodTom Tromey1-2/+2
This changes value_bits_synthetic_pointer to be a method of value. 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 value_zero into static "constructor"Tom Tromey1-1/+1
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_computed_value into static "constructor"Tom Tromey1-1/+1
This turns allocate_computed_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-3/+3
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_initialized and set_value_initialized functions into methodsTom Tromey1-1/+1
This changes the value_initialized and set_value_initialized functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_computed_closure and value_computed_funcs functions into methodsTom Tromey1-6/+6
This changes the value_computed_funcs and value_computed_closure functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_stack and set_value_stack functions into methodsTom Tromey1-1/+1
This changes the value_stack and set_value_stack functions to be methods of value. 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 value_offset into methodTom Tromey1-5/+5
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_parent into methodTom Tromey1-1/+1
This changes value_parent 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_bitpos into methodTom Tromey1-3/+3
This changes value_bitpos 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_bitsize into methodTom Tromey1-5/+5
This changes value_bitsize 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-38/+38
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-10gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.Rohr, Stephan1-3/+0
The 'rw_pieced_value' function is executed when fetching a (lazy) variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The function checks the 'type' and 'enclosing_type' fields of the value for identity. * The 'type' field describes the type of a value. * In most cases, the 'enclosing_type' field is identical to the 'type' field. * Scenarios where the 'type' and 'enclosing_type' of an object differ are described in 'gdb/value.c'. Possible cases are: * If a value represents a C++ object, then the 'type' field gives the object's compile-time type. If the object actually belongs to some class derived from `type', perhaps with other base classes and additional members, then `type' is just a subobject of the real thing, and the full object is probably larger than `type' would suggest. * If 'type' is a dynamic class (i.e. one with a vtable), then GDB can actually determine the object's run-time type by looking at the run-time type information in the vtable. GDB may then elect to read the entire object. * If the user casts a variable to a different type (e.g. 'print (<type> []) <variable>'), the value's type is updated before reading the value. If a lazy value is fetched, GDB allocates space based on the enclosing type's length and typically reads the 'full' object. This is not implemented for pieced values and causes an internal error if 'type' and 'enclosing_type' of a value are not identical. However, GDB can read the value based on its type. Thus, this patch fixes the previously mentioned cases by removing the check for identity. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28605 gdb/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * dwarf2/loc.c (rw_pieced_value): Fix check on 'type' and 'enlcosing_type' when reading pieced value 'v'. gdb/testsuite/ChangeLog: 2022-04-13 Stephan Rohr <stephan.rohr@intel.com> * gdb.dwarf2/shortpiece.exp: Added test cases.
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-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-6/+4
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-10/+10
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-20/+20
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-08-18gdb: call check_typedef at beginning of dwarf_expr_context::fetch_resultSimon Marchi1-0/+5
Bug 29374 shows this crash: $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out ... /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. The backtrace is: #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 The problem is that the type that gets passed down to dwarf_expr_context::fetch_result (the type of a variable of which we're trying to read the entry value) is a typedef whose size has never been computed yet (check_typedef has never been called on it). As we get in the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` variable is therefore set to 0, instead of the actual type length. We then call allocate_value on subobj_type, which does call check_typedef, so the length of the typedef gets filled in at that point. We end up passing to the copy function a source array view of length 0 and a target array view of length 4, and the assertion fails. Fix this by calling check_typedef on both type and subobj_type at the beginning of fetch_result. I tried writing a test for this using the DWARF assembler, but I haven't succeeded. It's possible that we need to get into this specific code path (value_of_dwarf_reg_entry and all) to manage to get to dwarf_expr_context::fetch_result with a typedef type that has never been resolved. In all my attempts, the typedef would always be resolved already, so the bug wouldn't show up. As a fallback, I made a gdb.dwarf2 test with compiler-generated .S files. I don't particularly like those, but I think it's better than no test. The .cpp source code is the smallest reproducer I am able to make from the reproducer given in the bug (thanks to Pedro for suggestions on how to minimize it further than I had). Since I tested on both amd64 and aarch64, I added versions of the test for these two architectures. Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374
2022-08-04Use registry in gdbarchTom Tromey1-26/+6
gdbarch implements its own registry-like approach. This patch changes it to instead use registry.h. It's a rather large patch but largely uninteresting -- it's mostly a straightforward conversion from the old approach to the new one. The main benefit of this change is that it introduces type safety to the gdbarch registry. It also removes a bunch of code. One possible drawback is that, previously, the gdbarch registry differentiated between pre- and post-initialization setup. This doesn't seem very important to me, though.
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-5/+2
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-12-03gdbsupport: add array_view copy functionSimon Marchi1-2/+2
An assertion was recently added to array_view::operator[] to ensure we don't do out of bounds accesses. However, when the array_view is copied to or from using memcpy, it bypasses that safety. To address this, add a `copy` free function that copies data from an array view to another, ensuring that the destination and source array views have the same size. When copying to or from parts of an array_view, we are expected to use gdb::array_view::slice, which does its own bounds check. With all that, any copy operation that goes out of bounds should be caught by an assertion at runtime. copy is implemented using std::copy and std::copy_backward, which, at least on libstdc++, appears to pick memmove when copying trivial data. So in the end there shouldn't be much difference vs using a bare memcpy, as we do right now. When copying non-trivial data, std::copy and std::copy_backward assigns each element in a loop. To properly support overlapping ranges, we must use std::copy or std::copy_backward, depending on whether the destination is before the source or vice-versa. std::copy and std::copy_backward don't support copying exactly overlapping ranges (where the source range is equal to the destination range). But in this case, no copy is needed anyway, so we do nothing. The order of parameters of the new copy function is based on std::copy and std::copy_backward, where the source comes before the destination. Change a few randomly selected spots to use the new function, to show how it can be used. Add a test for the new function, testing both with arrays of a trivial type (int) and of a non-trivial type (foo). Test non-overlapping ranges as well as three kinds of overlapping ranges: source before dest, dest before source, and dest == source. Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03
2021-10-25gdb: change functions returning value contents to use gdb::array_viewSimon Marchi1-9/+9
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-10-05Add lval_funcs::is_optimized_outTom Tromey1-12/+44
This adds an is_optimized_out function pointer to lval_funcs, and changes value_optimized_out to call it. This new function lets gdb determine if a value is optimized out without necessarily fetching the value. This is needed for a subsequent patch, where an attempt to access a lazy value would fail due to the value size limit -- however, the access was only needed to determine the optimized-out state.
2021-08-16Fix register regression in DWARF evaluatorTom Tromey1-1/+3
On an internal test case, using an arm-elf target, commit ba5bc3e5a92 ("Make DWARF evaluator return a single struct value") causes a regression. (It doesn't happen for any of the other cross targets that I test when importing upstream gdb.) I don't know if there's an upstream gdb test case showing the same problem... I can only really run native tests with dejagnu AFAIK. The failure manifests like this: Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5 Whereas when it works it looks like: Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5 The difference is that the new code uses the passed-in gdbarch, whereas the old code used the frame's gdbarch, when handling DWARF_VALUE_REGISTER. This patch restores the use of the frame's arch.
2021-08-16Fix Ada regression due to DWARF expression seriesTom Tromey1-1/+3
Commit 0579205aec4 ("Simplify dwarf_expr_context class interface") caused a regression in the internal AdaCore test suite. I didn't try to reproduce this with the GDB test suite, but the test is identical to gdb.dwarf2/dynarr-ptr.exp. The problem is that this change: case DW_OP_push_object_address: /* Return the address of the object we are currently observing. */ - if (this->data_view.data () == nullptr - && this->obj_address == 0) + if (this->m_addr_info == nullptr) ... slightly changes the logic here. In particular, it's possible for the caller to pass in a non-NULL m_addr_info, but one that looks like: (top) p *this.m_addr_info $15 = { type = 0x29b7a70, valaddr = { m_array = 0x0, m_size = 0 }, addr = 0, next = 0x0 } In this case, an additional check is needed. With the current code, what happens instead is that the computation computes an incorrect address -- but one that does not fail in read_memory, due to the precise memory map of the embedded target in question. This patch restores the old logic.
2021-08-08Include objfiles.h in a few .c filesTom Tromey1-0/+1
I found a few .c files that rely on objfiles.h, but that only include it indirectly, via dwarf2/read.h -> psympriv.h. If that include is removed (something my new DWARF indexer series does), then the build will break. It seemed harmless and correct to add these includes now, making the eventual series a little smaller.
2021-08-05Add as_lval argument to expression evaluatorZoran Zaric1-3/+8
There are cases where the result of the expression evaluation is expected to be in a form of a value and not location description. One place that has this requirement is dwarf_entry_parameter_to_value function, but more are expected in the future. Until now, this requirement was fulfilled by extending the evaluated expression with a DW_OP_stack_value operation at the end. New implementation, introduces a new evaluation argument instead. * dwarf2/expr.c (dwarf_expr_context::fetch_result): Add as_lval argument. (dwarf_expr_context::eval_exp): Add as_lval argument. * dwarf2/expr.h (struct dwarf_expr_context): Add as_lval argument to fetch_result and eval_exp methods. * dwarf2/frame.c (execute_stack_op): Add as_lval argument. * dwarf2/loc.c (dwarf_entry_parameter_to_value): Remove DWARF expression extension. (dwarf2_evaluate_loc_desc_full): Add as_lval argument support. (dwarf2_evaluate_loc_desc): Add as_lval argument support. (dwarf2_locexpr_baton_eval): Add as_lval argument support.
2021-08-05Simplify dwarf_expr_context class interfaceZoran Zaric1-163/+185
Idea of this patch is to get a clean and simple public interface for the dwarf_expr_context class, looking like: - constructor, - destructor, - push_address method and - evaluate method. Where constructor should only ever require a target architecture information. This information is held in per object file (dwarf2_per_objfile) structure, so it makes sense to keep that structure as a constructor argument. It also makes sense to get the address size from that structure, but unfortunately that interface doesn't exist at the moment, so the dwarf_expr_context class user needs to provide that information. The push_address method is used to push a CORE_ADDR as a value on top of the DWARF stack before the evaluation. This method can be later changed to push any struct value object on the stack. The evaluate method is the method that evaluates a DWARF expression and provides the evaluation result, in a form of a single struct value object that describes a location. To do this, the method requires a context of the evaluation, as well as expected result type information. If the type information is not provided, the DWARF generic type will be used instead. To avoid storing the gdbarch information in the evaluator object, that information is now always acquired from the per_objfile object. All data members are now private and only visible to the evaluator class, so a m_ prefix was added to all of their names to reflect that. To make this distinction clear, they are also accessed through objects this pointer, wherever that was not the case before. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add address size argument. (dwarf_expr_context::read_mem): Change to use property_addr_info structure. (dwarf_expr_context::evaluate): New function. (dwarf_expr_context::execute_stack_op): Change to use property_addr_info structure. * dwarf2/expr.h (struct dwarf_expr_context): New evaluate declaration. Change eval and fetch_result method to private. (dwarf_expr_context::gdbarch): Remove member. (dwarf_expr_context::stack): Make private and add m_ prefix. (dwarf_expr_context::addr_size): Make private and add m_ prefix. (dwarf_expr_context::recursion_depth): Make private and add m_ prefix. (dwarf_expr_context::max_recursion_depth): Make private and add m_ prefix. (dwarf_expr_context::len): Make private and add m_ prefix. (dwarf_expr_context::data): Make private and add m_ prefix. (dwarf_expr_context::initialized): Make private and add m_ prefix. (dwarf_expr_context::pieces): Make private and add m_ prefix. (dwarf_expr_context::per_objfile): Make private and add m_ prefix. (dwarf_expr_context::frame): Make private and add m_ prefix. (dwarf_expr_context::per_cu): Make private and add m_ prefix. (dwarf_expr_context::addr_info): Make private and add m_ prefix. * dwarf2/frame.c (execute_stack_op): Change to call evaluate method. * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to call evaluate method. (dwarf2_locexpr_baton_eval): Change to call evaluate method.
2021-08-05Make DWARF evaluator return a single struct valueZoran Zaric1-3/+156
The patch is addressing the issue of class users writing and reading the internal data of the dwarf_expr_context class. At this point, all conditions are met for the DWARF evaluator to return an evaluation result in a form of a single struct value object. gdb/ChangeLog: * dwarf2/expr.c (pieced_value_funcs): Chenge to static function. (allocate_piece_closure): Change to static function. (dwarf_expr_context::fetch_result): New function. * dwarf2/expr.h (struct piece_closure): Remove declaration. (struct dwarf_expr_context): fetch_result new declaration. fetch, fetch_address and fetch_in_stack_memory members move to private. (allocate_piece_closure): Remove. * dwarf2/frame.c (execute_stack_op): Change to use fetch_result. * dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Change to use fetch_result. (dwarf2_locexpr_baton_eval): Change to use fetch_result. * dwarf2/loc.h (invalid_synthetic_pointer): Expose function.
2021-08-05Move piece_closure and its support to expr.cZoran Zaric1-0/+571
Following 5 patches series is trying to clean up the interface of the DWARF expression evaluator class (dwarf_expr_context). After merging all expression evaluators into one class, the next logical step is to make a clean user interface for that class. To do that, we first need to address the issue of class users writing and reading the internal data of the class directly. Fixing the case of writing is simple, it makes sense for an evaluator instance to be per architecture basis. Currently, the best separation seems to be per object file, so having that data (dwarf2_per_objfile) as a constructor argument makes sense. It also makes sense to get the address size from that object file, but unfortunately that interface does not exist at the moment. Luckily, address size information is already available to the users through other means. As a result, the address size also needs to be a class constructor argument, at least until a better interface for acquiring that information from an object file is implemented. The rest of the user written data comes down to a context of an evaluated expression (compilation unit context, frame context and passed in buffer context) and a source type information that a result of evaluating expression is representing. So, it makes sense for all of these to be arguments of an evaluation method. To address the problem of reading the dwarf_expr_context class internal data, we first need to understand why it is implemented that way? This is actualy a question of which existing class can be used to represent both values and a location descriptions and why it is not used currently? The answer is in a struct value class/structure, but the problem is that before the evaluators were merged, only one evaluator had an infrastructure to resolve composite and implicit pointer location descriptions. After the merge, we are now able to use the struct value to represent any result of the expression evaluation. It also makes sense to move all infrastructure for those location descriptions to the expr.c file considering that that is the only place using that infrastructure. What we are left with in the end is a clean public interface of the dwarf_expr_context class containing: - constructor, - destructor, - push_address method and - eval_exp method. The idea with this particular patch is to move piece_closure structure and the interface that handles it (lval_funcs) to expr.c file. While implicit pointer location descriptions are still not useful in the CFI context (of the AMD's DWARF standard extensions), the composite location descriptions are certainly necessary to describe a results of specific compiler optimizations. Considering that a piece_closure structure is used to represent both, there was no benefit in splitting them. gdb/ChangeLog: * dwarf2/expr.c (struct piece_closure): Add from loc.c. (allocate_piece_closure): Add from loc.c. (bits_to_bytes): Add from loc.c. (rw_pieced_value): Add from loc.c. (read_pieced_value): Add from loc.c. (write_pieced_value): Add from loc.c. (check_pieced_synthetic_pointer): Add from loc.c. (indirect_pieced_value): Add from loc.c. (coerce_pieced_ref): Add from loc.c. (copy_pieced_value_closure): Add from loc.c. (free_pieced_value_closure): Add from loc.c. (sect_variable_value): Add from loc.c. * dwarf2/loc.c (sect_variable_value): Move to expr.c. (struct piece_closure): Move to expr.c. (allocate_piece_closure): Move to expr.c. (bits_to_bytes): Move to expr.c. (rw_pieced_value): Move to expr.c. (read_pieced_value): Move to expr.c. (write_pieced_value): Move to expr.c. (check_pieced_synthetic_pointer): Move to expr.c. (indirect_pieced_value): Move to expr.c. (coerce_pieced_ref): Move to expr.c. (copy_pieced_value_closure): Move to expr.c. (free_pieced_value_closure): Move to expr.c.
2021-08-05Merge evaluate_for_locexpr_baton evaluatorZoran Zaric1-2/+18
The evaluate_for_locexpr_baton is the last derived class from the dwarf_expr_context class. It's purpose is to support the passed in buffer functionality. Although, it is not really necessary to merge this class with it's base class, doing that simplifies new expression evaluator design. Considering that this functionality is going around the DWARF standard, it is also reasonable to expect that with a new evaluator design and extending the push object address functionality to accept any location description, there will be no need to support passed in buffers. Alternatively, it would also makes sense to abstract the interaction between the evaluator and a given resource in the near future. The passed in buffer would then be a specialization of that abstraction. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::read_mem): Merge with evaluate_for_locexpr_baton implementation. * dwarf2/loc.c (class evaluate_for_locexpr_baton): Remove class. (evaluate_for_locexpr_baton::read_mem): Move to dwarf_expr_context. (dwarf2_locexpr_baton_eval): Instantiate dwarf_expr_context instead of evaluate_for_locexpr_baton class.
2021-08-05Inline get_reg_value method of dwarf_expr_contextZoran Zaric1-17/+7
The get_reg_value method is a small function that is only called once, so it can be inlined to simplify the dwarf_expr_context class. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::get_reg_value): Remove method. (dwarf_expr_context::execute_stack_op): Inline get_reg_value method. * dwarf2/expr.h (dwarf_expr_context::get_reg_value): Remove method.
2021-08-05Move push_dwarf_reg_entry_value to expr.cZoran Zaric1-0/+50
Following the idea of merging the evaluators, the push_dwarf_reg_entry_value method can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::push_dwarf_reg_entry_value): Move from dwarf_evaluate_loc_desc. * dwarf2/frame.c (dwarf_expr_executor::push_dwarf_reg_entry_value): Remove method. * dwarf2/loc.c (dwarf_expr_reg_to_entry_parameter): Expose function. (dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value): Move to dwarf_expr_context. * dwarf2/loc.h (dwarf_expr_reg_to_entry_parameter): Expose function.
2021-08-05Move read_mem to dwarf_expr_contextZoran Zaric1-0/+9
Following the idea of merging the evaluators, the read_mem method can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::read_mem): Move from dwarf_evaluate_loc_desc. * dwarf2/frame.c (dwarf_expr_executor::read_mem): Remove method. * dwarf2/loc.c (dwarf_evaluate_loc_desc::read_mem): Move to dwarf_expr_context.
2021-08-05Move dwarf_call to dwarf_expr_contextZoran Zaric1-1/+27
Following the idea of merging the evaluators, the dwarf_call and get_frame_pc method can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context. Once this is done, the get_frame_pc can be replace with lambda function. gdb/ChangeLog: * dwarf2/expr.c (dwarf_expr_context::dwarf_call): Move from dwarf_evaluate_loc_desc. (dwarf_expr_context::get_frame_pc): Replace with lambda. * dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove method. * dwarf2/frame.c (dwarf_expr_executor::dwarf_call): Remove method. (dwarf_expr_executor::get_frame_pc): Remove method. * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_pc): Remove method. (dwarf_evaluate_loc_desc::dwarf_call): Move to dwarf_expr_context. (per_cu_dwarf_call): Inline function.
generated by cgit v1.1 at 2025-04-08 07:34:54 +0000