mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-23 11:39:26 +08:00
945e66a74d
The following GDB behavior was also reported as a GDB bug in https://sourceware.org/bugzilla/show_bug.cgi?id=28396 I will reiterate the problem a bit and give some more information here. This patch closes the above mentioned bug. The DWARF 5 standard 2.23 'Template Parameters' reads: A template type parameter is represented by a debugging information entry with the tag DW_TAG_template_type_parameter. A template value parameter is represented by a debugging information entry with the tag DW_TAG_template_value_parameter. The actual template parameter entries appear in the same order as the corresponding template formal parameter declarations in the source progam. A type or value parameter entry may have a DW_AT_name attribute, whose value is a null-terminated string containing the name of the corresponding formal parameter. So the DW_AT_name attribute for DW_TAG_template_type_parameter and DW_TAG_template_value_parameter is optional. Within GDB, creating a new symbol from some read DIE usually requires the presence of a DW_AT_name for the DIE (an exception here is the case of unnamed namespaces or the existence of a linkage name). This patch makes the presence of the DW_AT_name for template value/type tags optional, similar to the unnamed namespaces. For unnamed namespaces dwarf2_name simply returns the constant string CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a case was added to the switch statement calling the unnamed_template_tag_name helper. Within the scope of parent which the template parameter is a child of, the helper counts the position of the template tag within the unnamed template tags and returns '<unnamedNUMBER>' where NUMBER is its position. This way we end up with unique names within the respective scope of the function/class/struct (these are the only currenltly supported template kinds within GDB and usually the compilers) where we discovered the template tags in. While I do not know of a way to bring GCC to emit template tags without names there is one for clang/icpx. Consider the following example template<typename A, typename B, typename C> class Foo {}; template<typename, typename B, typename> class Foo; int main () { Foo<double, int, float> f; return 0; } The forward declaration for 'Foo' with the missing template type names 'A' and 'C' makes clang emit a bunch of template tags without names: ... <2><43>: Abbrev Number: 3 (DW_TAG_variable) <44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8) <47> DW_AT_name : (indirect string, offset: 0x63): f <4b> DW_AT_decl_file : 1 <4c> DW_AT_decl_line : 8 <4d> DW_AT_type : <0x59> ... <1><59>: Abbrev Number: 5 (DW_TAG_class_type) <5a> DW_AT_calling_convention: 5 (pass by value) <5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float> <5f> DW_AT_byte_size : 1 <60> DW_AT_decl_file : 1 <61> DW_AT_decl_line : 2 <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param) <63> DW_AT_type : <0x76> <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param) <68> DW_AT_type : <0x52> <6c> DW_AT_name : (indirect string, offset: 0x6c): B <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param) <71> DW_AT_type : <0x7d> ... Befor this patch, GDB would not create any symbols for the read template tag DIEs and thus lose knowledge about them. Breaking at the return statement and printing f's type would read (gdb) ptype f type = class Foo<double, int, float> [with B = int] { <no data fields> } After this patch GDB does generate symbols from the DWARF (with their artificial names: (gdb) ptype f type = class Foo<double, int, float> [with <unnamed0> = double, B = int, <unnamed1> = float] { <no data fields> } The same principle theoretically applies to template functions. Also here, GDB would not record unnamed template TAGs but I know of no visual way to trigger and test this changed behavior. Template functions do not emit a '[with...]' list and their name generation also does not suffer from template tags without names. GDB does not check whether or not a template tag has a name in 'dwarf2_compute_name' and thus, the names of the template functions are created independently of whether or not the template TAGs have a DW_TAT_name attribute. A testcase has been added in the gdb.dwarf2 for template classes and structs. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396
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.