forked from Imagelibrary/binutils-gdb
0dd1a71b4d
The rest of the patch series addresses the issues described in a "Motivation" section of the AMD's DWARF standard extensions that can be found at: https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html The document describes a couple of main issues found when using the current DWARF 5 version to describe optimized code for SIMD and SIMT architectures. Without going much into details described in the document, the main point is that DWARF version 5 does not allow a proper support for address spaces and it does not allow a location description to be used anywhere in the DWARF expression, instead a location description can using a result left on the DWARF stack (after the evaluation of that expression) to describe the location. Both issues can be solved in a clean way by introducing a new set of classes that describe all entry types which can be placed on a DWARF stack, while keeping most of backward compatibility with the previous standard version. These entry types can now be either a typed value or any location description. Known edge case where placing a location description on the DWARF stack is not fully backward compatible with DWARF version 5 is in the case of DW_OP_call operations, where the current standard only defines that an expression stack is shared between the caller and the callee, but there it is unknown what happens with the resuling location description after the evaluation of the callee's location description expression. Considering that this edge case is not defined in the standard, it would be very unusual and dangerous for any compiler to use it in their own way and in the existing testsuite, there is no indication of that. Currently, the result of an expression evaluation is kept in a separate data structure, while with the new approach, it will be always found as a top element of the DWARF stack. Question here is, why do we need a new set of classes and why not just use the struct value instead? As it stands, there are couple of issues with using the struct value to describe a DWARF stack element: - It is not designed to represent a DWARF location description specifically, instead it behaves more like unified debug information format that represents an actual target resource. One example of this is accessing data of a struct value register location description, where if the amount of data accessed is larger then the register, results in accessing more then one register. In DWARF this is not a valid behavior and locations that span more then one register should be described as a composite location description. - There is a tight coupling between struct value and it's type information, regardless if the data represented is describing a value (not_lval) or a location description. While the type information dictates how the data is accessed for a struct value case, in DWARF, location description doesn't have a type so data access is not bound by it. - DWARF values only support much simpler base types, while struct value can be linked to any type. Admittedly, new classes are still using the same struct value infrastructure for a value based operations at the moment, but that is planned to change in the near future. - struct value register location description requires a frame id information which makes them unsuitable for CFA expression evaluation. So, there seems to be a lack of separation of concerns in the design of a struct value infrastructure, while the new classes are handling one specific purpose and are completely encapsulated in the expr.c. Additional benefit of this design is that it makes a step in a right direction for being able to evaluate DWARF expressions on a gdbserver side in the near future, which sounds like a desirable thing. It is also worth mentioning that this new location description representation is based on a bit granularity (the bit_suboffset class member) even though the DWARF standard has a very limited support for it (mostly used for DW_OP_bit_piece operation). By allowing any location description to define a bit sub-offset of the location, we are able to give more options for supporting of new concepts (like the existing packed arrays in Ada language). In this patch, a new set of classes that describe a DWARF stack element are added. The new classes are: - Value - describes a numerical value with a DWARF base type. - Location description - describes a DWARF location description. - Undefined location - describes a location that is not defined. - Memory location - describes a location in memory. - Register location - describes a register location in a frame context. - Implicit location - describes a location that implicitly holds a value that it describes. - Implicit pointer - describes a concept of an implicit pointer to a source variable. - Composite location - describes a location that is composed from pieces of other location descriptions. For now, these classes are just defined, and they are planned to be used by the following patches. gdb/ChangeLog: * dwarf2/expr.c (class dwarf_entry): New class. (class dwarf_value): New class. (class dwarf_location): New class. (class dwarf_undefined): New class. (class dwarf_memory): New class. (class dwarf_register): New class. (class dwarf_implicit): New class. (class dwarf_implicit_pointer): New class. (class dwarf_composite): New class. * value.c (pack_unsigned_long): Expose function. * value.h (pack_unsigned_long): Expose function.
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.