public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "brobecker at gnat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/16581] GDB crash on inherit_abstract_dies infinite recursion
Date: Fri, 14 Feb 2014 03:26:00 -0000	[thread overview]
Message-ID: <bug-16581-4717-nViFRqVNGs@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16581-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=16581

--- Comment #1 from Joel Brobecker <brobecker at gnat dot com> ---
>From https://www.sourceware.org/ml/gdb-patches/2014-01/msg00805.html:

For the record, we've actually seen the exact same behavior from
with GNAT a few years ago.  The problem occured when when we had
the following situation:

   procedure Outer (...) is
      [...]
      procedure Inner (...) is
         [...]
         -- Recurse by calling Outer..
         Outer (...);
      end Inner;
   begin
      [...]
      Inner (...);

In that case, when compiled at -O3, the compiler generated an Abstract
Instance Root (AIR) for procedure Outer, which owned/contained a DIE
defining procedure Inner (an out-of-line instance), which itself
contains a Concrete Instance Entry (CIIE) corresponding to the inlined
version of Outer's AIR. The CIIE has a reference to its AIR via
the DW_AT_abstract_origin attribute, hence the cycle.

Not being all quite sure how to make sense of the cycle in terms of
inheritance, we initially tried to fix in the compiler.  Although
the patch was initially approved in GCC, it was noted that the output
appeared to be conformant with the DWARF specifications (version 3,i
at the time, now version 4), particularly in light of the examples
in section D.7 of the specifications (3rd example).

Eventually, it was found that our GCC patch was causing some issues,
and thus was reverted. So far, we've kept the patch in AdaCore's
GCC tree, with a note to look into a GDB fix at some point.

We are indeed very close to the example from the DWARF specs cited
above, but it does not deal with recursion as we do here, so I think
that the DWARF specifications do have a hole when it comes to that.
Logically speaking, its seems that the sensible thing to do is to
inherit the whole Abstract Instance Tree (AIT) but excluding oneself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


  parent reply	other threads:[~2014-02-14  3:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14  3:24 [Bug symtab/16581] New: " brobecker at gnat dot com
2014-02-14  3:25 ` [Bug symtab/16581] " brobecker at gnat dot com
2014-02-14  3:26 ` brobecker at gnat dot com [this message]
2014-02-14  3:28 ` brobecker at gnat dot com
2014-02-14  3:32 ` brobecker at gnat dot com
2014-02-14  3:33 ` brobecker at gnat dot com
2014-02-20 17:16 ` cvs-commit at gcc dot gnu.org
2014-02-24 20:13 ` jan.kratochvil at redhat dot com
2014-02-24 20:57 ` brobecker at gnat dot com

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=bug-16581-4717-nViFRqVNGs@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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).