aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2/expr.c
AgeCommit message (Collapse)AuthorFilesLines
2020-09-14gdb: remove TYPE_UNSIGNEDSimon Marchi1-3/+3
gdb/ChangeLog: * gdbtypes.h (TYPE_UNSIGNED): Remove, replace all uses with type::is_unsigned. Change-Id: I84f76f5cd44ff7294e421d317376a9e476bc8666
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey1-1/+2
A modified version of the gnat compiler (TBH I don't know if the modifications are relevant to this bug or not, but I figured I'd mention it) can generate a DWARF location expression like: <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure) <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop) <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type) <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and) When evaluated, this gives: Incompatible types on DWARF stack In Jakub's original message about DW_OP_GNU_variable_value: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html .. it says: The intended behavior is that the debug info consumer computes the value of that referenced variable at the current PC, and if it can compute it and pushes the value as a generic type integer into the DWARF stack Instead, gdb is using the variable's type -- but this fails with some operations, like DW_OP_and, which expect the types to match. I believe what was intended was for the value to be cast to the DWARF "untyped" type, which is what this patch implements. This patch also updates varval.exp to exhibit the bug. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op) <DW_OP_GNU_variable_value>: Cast to address type. gdb/testsuite/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to 'varval' location.
2020-05-27Add dwarf2_per_objfile to dwarf_expr_context and dwarf2_frame_cacheSimon Marchi1-5/+6
Evaluating DWARF expressions (such as location expressions) requires knowing about the current objfile. For example, it may call functions like dwarf2_fetch_die_loc_sect_off, which currently obtain the dwarf2_per_objfile object it needs from the dwarf2_per_cu_data object. However, since we are going to remove this dwarf2_per_cu_data::dwarf2_per_objfile link, these functions will need to obtain the current dwarf2_per_objfile by parmeter. If we go up the stack, we see that the DWARF expression contexts (dwarf_expr_context and the classes that derive from it) need to store the dwarf2_per_objfile, to be able to pass it to those functions that will need it. This patch adds a constructor to all these dwarf_expr_context variants, accepting a dwarf2_per_objfile parameter. This dwarf2_per_objfile generally comes from a symbol baton created earlier. For frame-related expressions, the dwarf2_per_objfile object must be passed through the dwarf2_frame_cache object. This lead to the dwarf2_frame_find_fde function returning (by parameter) a dwarf2_per_objfile object. I then realized that this made the existing "out_offset" parameter redundant. This offset is `objfile->text_section_offset ()`, so it can be recomputed from the dwarf2_per_objfile object at any time. I therefore opted to remove this output parameter, as well as the offset field of dwarf2_frame_cache. *Note*, there's one spot I'm particularly unsure about. In dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value, we would save and overwrite the offset value in the context, along with a bunch of other state. This is because we might be about to evaluate something in a different CU that the current one. If the two CUs are in the same objfile, then the text_offset is the same, as it's a property of the objfile. However, if the two CUs are possibly in different objfiles, then it means the text_offsets are different. It would also mean we would need to save and restore the dwarf2_per_objfile in the context. Is that even possible? gdb/ChangeLog: * dwarf2/expr.h (struct dwarf_expr_context) <dwarf_expr_context>: Add dwarf2_per_objfile parameter. <offset>: Remove. <per_objfile>: New member. * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add dwarf2_per_objfile parameter. Don't set offset, set per_objfile. (dwarf_expr_context::execute_stack_op): Use offset from objfile. * dwarf2/frame.c (dwarf2_frame_find_fde): Return (by parameter) a dwarf2_per_objfile object instead of an offset. (class dwarf_expr_executor) <dwarf_expr_executor>: Add constructor. (execute_stack_op): Add dwarf2_per_objfile parameter, pass it to dwarf2_expr_executor constructor. Don't set offset. (dwarf2_fetch_cfa_info): Update. (struct dwarf2_frame_cache) <text_offset>: Remove. <per_objfile>: New field. (dwarf2_frame_cache): Update. (dwarf2_frame_prev_register): Update. * dwarf2/loc.c (class dwarf_evaluate_loc_desc) <dwarf_evaluate_loc_desc>: Add constructor. (dwarf2_evaluate_loc_desc_full): Update. (dwarf2_locexpr_baton_eval): Update. (class symbol_needs_eval_context) <symbol_needs_eval_context>: Add constructor. (dwarf2_loc_desc_get_symbol_read_needs): Update. Change-Id: I14df060669cc36ad04759f1708c6d7b1fda77727
2020-05-14gdb: remove TYPE_CODE macroSimon Marchi1-4/+4
Remove TYPE_CODE, changing all the call sites to use type::code directly. This is quite a big diff, but this was mostly done using sed and coccinelle. A few call sites were done by hand. gdb/ChangeLog: * gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use type::code instead.
2020-02-08Move DWARF code to dwarf2/ subdirectoryTom Tromey1-0/+1428
This moves all the remaining DWARF code to the new dwarf2 subdirectory. This is just a simple renaming, with updates to includes as needed. gdb/ChangeLog 2020-02-08 Tom Tromey <tom@tromey.com> * dwarf2/expr.c: Rename from dwarf2expr.c. * dwarf2/expr.h: Rename from dwarf2expr.h. * dwarf2/frame-tailcall.c: Rename from dwarf2-frame-tailcall.c. * dwarf2/frame-tailcall.h: Rename from dwarf2-frame-tailcall.h. * dwarf2/frame.c: Rename from dwarf2-frame.c. * dwarf2/frame.h: Rename from dwarf2-frame.h. * dwarf2/index-cache.c: Rename from dwarf-index-cache.c. * dwarf2/index-cache.h: Rename from dwarf-index-cache.h. * dwarf2/index-common.c: Rename from dwarf-index-common.c. * dwarf2/index-common.h: Rename from dwarf-index-common.h. * dwarf2/index-write.c: Rename from dwarf-index-write.c. * dwarf2/index-write.h: Rename from dwarf-index-write.h. * dwarf2/loc.c: Rename from dwarf2loc.c. * dwarf2/loc.h: Rename from dwarf2loc.h. * dwarf2/read.c: Rename from dwarf2read.c. * dwarf2/read.h: Rename from dwarf2read.h. * dwarf2/abbrev.c, aarch64-tdep.c, alpha-tdep.c, amd64-darwin-tdep.c, arc-tdep.c, arm-tdep.c, bfin-tdep.c, compile/compile-c-symbols.c, compile/compile-cplus-symbols.c, compile/compile-loc2c.c, cris-tdep.c, csky-tdep.c, findvar.c, gdbtypes.c, guile/scm-type.c, h8300-tdep.c, hppa-bsd-tdep.c, hppa-linux-tdep.c, i386-darwin-tdep.c, i386-linux-tdep.c, i386-tdep.c, iq2000-tdep.c, m32c-tdep.c, m68hc11-tdep.c, m68k-tdep.c, microblaze-tdep.c, mips-tdep.c, mn10300-tdep.c, msp430-tdep.c, nds32-tdep.c, nios2-tdep.c, or1k-tdep.c, riscv-tdep.c, rl78-tdep.c, rs6000-tdep.c, rx-tdep.c, s12z-tdep.c, s390-tdep.c, score-tdep.c, sh-tdep.c, sparc-linux-tdep.c, sparc-tdep.c, sparc64-linux-tdep.c, sparc64-tdep.c, tic6x-tdep.c, tilegx-tdep.c, v850-tdep.c, xstormy16-tdep.c, xtensa-tdep.c: Update. * Makefile.in (COMMON_SFILES): Update. (HFILES_NO_SRCDIR): Update. Change-Id: Ied9ce1436cd27ac4a4cffef10ec92e396f181928