public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Kevin Buettner <kevinb@redhat.com>
Subject: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs
Date: Mon, 14 Oct 2019 00:19:00 -0000	[thread overview]
Message-ID: <20191014001842.27413-2-kevinb@redhat.com> (raw)
In-Reply-To: <20191014001842.27413-1-kevinb@redhat.com>

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 fix causes 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.

Another way to fix it might be call compute_delayed_physnames() from
inherit_abstract_dies(), but I wasn't confident that all needed types
would be known at that point.  It seemed safer to defer the physname
computation until the inheriting CU is completely processed.

gdb/ChangeLog:

	* dwarf2read.c (inherit_abstract_dies): Ensure that delayed
	physnames are computed for inherited DIEs.
---
 gdb/dwarf2read.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index ee9df34ed2..f7ef122933 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -13666,6 +13666,17 @@ inherit_abstract_dies (struct die_info *die, struct dwarf2_cu *cu)
       origin_child_die = sibling_die (origin_child_die);
     }
   origin_cu->list_in_scope = origin_previous_list_in_scope;
+
+  if (cu != origin_cu && !origin_cu->method_list.empty ())
+    {
+      /* Add list of methods found in origin_cu to the list in cu.  These
+         methods still need to have their physnames computed in
+	 compute_delayed_physnames().  */
+      cu->method_list.insert (cu->method_list.end (),
+                              origin_cu->method_list.begin (),
+			      origin_cu->method_list.end ());
+      origin_cu->method_list.clear ();
+    }
 }
 
 static void
-- 
2.21.0

  parent reply	other threads:[~2019-10-14  0:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14  0:19 [PATCH 0/2] Fix BZ 25065 (LTO related GDB segfault) Kevin Buettner
2019-10-14  0:19 ` [PATCH 2/2] Test case for BZ 25065 Kevin Buettner
2019-12-08 10:29   ` [committed] Fix inter-CU references using intra-CU form in imported-unit Tom de Vries
2019-10-14  0:19 ` Kevin Buettner [this message]
2019-10-14  3:02   ` [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs Simon Marchi
2019-10-15 16:27     ` Kevin Buettner
2019-10-17  3:54       ` Simon Marchi
2019-10-17  5:30         ` Simon Marchi
2019-10-18  1:08           ` Kevin Buettner
2019-10-18 15:07             ` Simon Marchi
2019-10-21 20:05               ` Keith Seitz
2019-10-22 22:23               ` Kevin Buettner
2019-11-04 20:42                 ` Kevin Buettner
2019-11-04 20:49                 ` Simon Marchi
2019-11-27 20:17                   ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191014001842.27413-2-kevinb@redhat.com \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).