Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: fix PR backtrace/15558
Date: Fri, 21 Jun 2013 21:21:00 -0000	[thread overview]
Message-ID: <87mwqjw613.fsf@fleche.redhat.com> (raw)
In-Reply-To: <51B11E66.70102@redhat.com> (Pedro Alves's message of "Fri, 07	Jun 2013 00:42:30 +0100")

Pedro> Yeah, I was suggesting that "internal" / non-user-facing code
Pedro> should not be using get_prev_frame, but get_prev_frame_1 instead,
Pedro> bypassing all the checks.  (Or rather wondering why that isn't
Pedro> so).  Strongly more so in an unwinder's innards.  get_prev_frame
Pedro> uses need to be investigated on a case-by-case manner manner to
Pedro> decide the best course of action, IMO.

I agree from a design standpoint that this is superior.

My main concern is that I am not confident that all the unwinders in the
tree actually stop sanely.  If we believe that they do then it seems
straightforward to do the split as you suggest.

Normally I don't like to code to work around potential bugs elsewhere.
However in some parts of gdb, like this one, it is difficult to do
otherwise, due to the testing problem.

Anyway, this is why I split the function where I did.

Pedro> So conceptually, in this case, I think what makes most sense it
Pedro> to skip _all_ the checks in get_prev_frame* that might return
Pedro> NULL, as there should always be a prev frame for an inline frame.
Pedro> IOW, in this case, I believe we should be making
Pedro> inline_frame_this_id call get_prev_frame_1, or whatever it gets
Pedro> renamed to, or equivalent.

That sounds reasonable.  I'll rework the patch next week.

Tom


  reply	other threads:[~2013-06-21 20:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 19:35 Tom Tromey
2013-06-06 23:42 ` Pedro Alves
2013-06-21 21:21   ` Tom Tromey [this message]
2014-04-10 23:56     ` Andrew Pinski
2014-04-14 18:06       ` Tom Tromey
2014-04-14 18:42         ` Pedro Alves
2014-04-14 18:52           ` Tom Tromey
2014-04-14 23:14             ` Pedro Alves
2014-04-16 20:03               ` Tom Tromey
2014-04-18  9:43                 ` Pedro Alves

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=87mwqjw613.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /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