forked from Imagelibrary/binutils-gdb
a03eab7536
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.