mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00
8d9a256865
This is a fix for BZ 25065.
GDB segfaults when running either gdb.cp/subtypes.exp or
gdb.cp/local.exp in conjunction with using the -flto compiler/linker
flag.
A much simpler program, which was used to help create the test for
this fix, is:
-- doit.cc --
int main()
{
class Foo {
public:
int doit ()
{
return 0;
}
};
Foo foo;
return foo.doit ();
}
-- end doit.cc --
gcc -o doit -flto -g doit.cc
gdb -q doit
Reading symbols from doit...
(gdb) ptype main::Foo
type = class Foo {
Segmentation fault (core dumped)
The segfault occurs due to a NULL physname in
c_type_print_base_struct_union in c-typeprint.c. Specifically,
calling is_constructor_name() eventually causes the SIGSEGV is this
code in c-typeprint.c:
const char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
int is_full_physname_constructor =
TYPE_FN_FIELD_CONSTRUCTOR (f, j)
|| is_constructor_name (physname)
|| is_destructor_name (physname)
|| method_name[0] == '~';
However, looking at compute_delayed_physnames(), we see that
the TYPE_FN_FIELD_PHYSNAME field should never be NULL. This
field will be set to "" for NULL physnames:
physname = dwarf2_physname (mi.name, mi.die, cu);
TYPE_FN_FIELD_PHYSNAME (fn_flp->fn_fields, mi.index)
= physname ? physname : "";
For this particular case, it turns out that compute_delayed_physnames
wasn't being called, which left TYPE_FN_FIELD_PHYSNAME set to the NULL
value that it started with when that data structure was allocated.
The place to fix it, I think, is towards the end of
inherit_abstract_dies().
My first attempt at fix caused the origin CU's method_list (which is
simply the list of methods whose physnames still need to be computed)
to be added to the CU which is doing the inheriting. One drawback
with this approach is that compute_delayed_physnames is (eventually)
called with a CU that's different than the CU in which the methods
were found. It's not clear whether this will cause problems or not.
A safer approach, which is what I ultimately settled on, is to call
compute_delayed_physnames() from inherit_abstract_dies(). One
potential drawback is that all needed types might not be known at that
point. However, in my testing, I haven't seen a problem along these
lines.
gdb/ChangeLog:
* dwarf2read.c (inherit_abstract_dies): Ensure that delayed
physnames are computed for inherited DIEs.
Change-Id: I6c6ffe96b301a9daab9f653956b89e3a33fa9445
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.