mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00

Following 15 patches in this patch series is cleaning up the design of the DWARF expression evaluator (dwarf_expr_context) to make future extensions of that evaluator easier and cleaner to implement. There are three subclasses of the dwarf_expr_context class (dwarf_expr_executor, dwarf_evaluate_loc_desc and evaluate_for_locexpr_baton). Here is a short description of each class: - dwarf_expr_executor is evaluating a DWARF expression in a context of a Call Frame Information. The overridden methods of this subclass report an error if a specific DWARF operation, represented by that method, is not allowed in a CFI context. The source code of this subclass lacks the support for composite as well as implicit pointer location description. - dwarf_evaluate_loc_desc can evaluate any expression with no restrictions. All of the methods that this subclass overrides are actually doing what they are intended to do. This subclass contains a full support for all location description types. - evaluate_for_locexpr_baton subclass is a specialization of the dwarf_evaluate_loc_desc subclass and it's function is to add support for passed in buffers. This seems to be a way to go around the fact that DWARF standard lacks a bit offset support for memory location descriptions as well as using any location description for the push object address functionality. It all comes down to this question: what is a function of a DWARF expression evaluator? Is it to evaluate the expression in a given context or to check the correctness of that expression in that context? Currently, the only reason why there is a dwarf_expr_executor subclass is to report an invalid DWARF expression in a context of a CFI, but is that what the evaluator is supposed to do considering that the evaluator is not tied to a given DWARF version? There are more and more vendor and GNU extensions that are not part of the DWARF standard, so is it that impossible to expect that some of the extensions could actually lift the previously imposed restrictions of the CFI context? Not to mention that every new DWARF version is lifting some restrictions anyway. The thing that makes more sense for an evaluator to do, is to take the context of an evaluation and checks the requirements of every operation evaluated against that context. With this approach, the evaluator would report an error only if parts of the context, necessary for the evaluation, are missing. If this approach is taken, then the unification of the dwarf_evaluate_loc_desc, dwarf_expr_executor and dwarf_expr_context is the next logical step. This makes a design of the DWARF expression evaluator cleaner and allows more flexibility when supporting future vendor and GNU extensions. Additional benefit here is that now all evaluators have access to all location description types, which means that a vendor extended CFI rules could support composite location description as well. This also means that a new evaluator interface can be changed to return a single struct value (that describes the result of the evaluation) instead of a caller poking around the dwarf_expr_context internal data for answers (like it is done currently). This patch starts the merging process by moving the frame context information and support from dwarf_expr_executor and dwarf_evaluate_loc_desc to dwarf_expr_context evaluator. The idea is to report an error when a given operation requires a frame information to be resolved, if that information is not present. gdb/ChangeLog: * dwarf2/expr.c (ensure_have_frame): New function. (read_addr_from_reg): Add from frame.c. (dwarf_expr_context::dwarf_expr_context): Add frame info to dwarf_expr_context. (dwarf_expr_context::read_addr_from_reg): Remove. (dwarf_expr_context::get_reg_value): Move from dwarf_evaluate_loc_desc. (dwarf_expr_context::get_frame_base): Move from dwarf_evaluate_loc_desc. (dwarf_expr_context::execute_stack_op): Call frame context info check. Remove use of read_addr_from_reg method. * dwarf2/expr.h (struct dwarf_expr_context): Add frame info member, read_addr_from_reg, get_reg_value and get_frame_base declaration. (read_addr_from_reg): Move to expr.c. * dwarf2/frame.c (read_addr_from_reg): Move to dwarf_expr_context. (dwarf_expr_executor::read_addr_from_reg): Remove. (dwarf_expr_executor::get_frame_base): Remove. (dwarf_expr_executor::get_reg_value): Remove. (execute_stack_op): Use read_addr_from_reg function instead of read_addr_from_reg method. * dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_base): Move to dwarf_expr_context. (dwarf_evaluate_loc_desc::get_reg_value): Move to dwarf_expr_context. (dwarf_evaluate_loc_desc::read_addr_from_reg): Remove. (dwarf2_locexpr_baton_eval):Use read_addr_from_reg function instead of read_addr_from_reg method.
…
…
…
…
…
…
…
…
…
…
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.
Description
Languages
C
51.8%
Makefile
22.4%
Assembly
12.3%
C++
6%
Roff
1.4%
Other
5.4%