Re: RFC: fix PR backtrace/15558

[Andrew Pinski <pinskia@gmail.com>]

On Fri, Jun 21, 2013 at 1:41 PM, Tom Tromey <tromey@redhat.com> wrote:
> 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.

Hi Tom,
  What happened to this patch, I don't see any reference to it latter
on?  I think I am running into the same problem as this patch is
fixing.

Thanks,
Andrew Pinski


>
> Tom