Infinite backtrace on (eg.) ARM

Infinite backtrace on (eg.) ARM

[Michael Snyder]

Been thinking about this problem.  Check me out here.

Taking a step or two back from the intimate view of gdb internals, 
the problem (if I understand it) is detecting the fact that we have
an unusual case of a function that doesn't save it's return address.
We have to detect the fact that we should stop the frame chain at
this function's frame.

So the most common case of a function that doesn't save its return
address is a leaf function, yes?  But we can distinguish that case
from the pathological case by looking at the frame->level.  A leaf
function can only be at frame level zero, unles we've made a dummy
frame on top of it via a target function call.

So we can check for:
  * doesn't save its PC, and
  * frame->level > 0, and
  * frame->next is not a call dummy.

Except that the information "doesn't save its PC" isn't public
at the point where we want it.  It's hidden within frame_register_unwind
and below -- in this case, in trad_frame.  So we sort of have a problem
of "what do we know, and when do we know it".

So -- what if we exported a method to make that info public?
It's rather specific, but in this case important: "does this
frame save its return address?"

Re: Infinite backtrace on (eg.) ARM

[Daniel Jacobowitz]

On Thu, Sep 21, 2006 at 06:48:44PM -0700, Michael Snyder wrote:
> So we can check for:
>   * doesn't save its PC, and
>   * frame->level > 0, and
>   * frame->next is not a call dummy.
> 
> Except that the information "doesn't save its PC" isn't public
> at the point where we want it.  It's hidden within frame_register_unwind
> and below -- in this case, in trad_frame.  So we sort of have a problem
> of "what do we know, and when do we know it".
> 
> So -- what if we exported a method to make that info public?
> It's rather specific, but in this case important: "does this
> frame save its return address?"

I think this is about the same as what I did in the third URL I sent
you.  I used a slightly roundabout way of answering the same question,
which didn't require a new interface: if we can tell that the frame is
deferring the question "where's my PC" to the next frame, then it
couldn't have saved the PC itself.

The second patch had some points of disagreement, but I think Mark and
I more or less agreed on the first one before I ran out of time to work
on it (I'll be back real soon, hopefully next week, to those), and the
third could probably be gotten into acceptable shape readily once the
first is in.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Infinite backtrace on (eg.) ARM

[Michael Snyder]

On Thu, 2006-09-21 at 22:59 -0400, Daniel Jacobowitz wrote:
> On Thu, Sep 21, 2006 at 06:48:44PM -0700, Michael Snyder wrote:
> > So we can check for:
> >   * doesn't save its PC, and
> >   * frame->level > 0, and
> >   * frame->next is not a call dummy.
> > 
> > Except that the information "doesn't save its PC" isn't public
> > at the point where we want it.  It's hidden within frame_register_unwind
> > and below -- in this case, in trad_frame.  So we sort of have a problem
> > of "what do we know, and when do we know it".
> > 
> > So -- what if we exported a method to make that info public?
> > It's rather specific, but in this case important: "does this
> > frame save its return address?"
> 
> I think this is about the same as what I did in the third URL I sent
> you.  I used a slightly roundabout way of answering the same question,
> which didn't require a new interface: if we can tell that the frame is
> deferring the question "where's my PC" to the next frame, then it
> couldn't have saved the PC itself.
> 
> The second patch had some points of disagreement, but I think Mark and
> I more or less agreed on the first one before I ran out of time to work
> on it (I'll be back real soon, hopefully next week, to those), and the
> third could probably be gotten into acceptable shape readily once the
> first is in.

OK, I get it.

And actually, the 3rd one works pretty well for me by itself
(with minor tweaking).

Would you be willing to see it go in that way, just to get 
something in there to handle the problem?  And put the other
parts in at your leisure?

I'll even do it for you.   ;-)

Michael

Ping, Re: Infinite backtrace on (eg.) ARM

[Michael Snyder]

On Fri, 2006-09-22 at 11:56 -0700, Michael Snyder wrote:
> On Thu, 2006-09-21 at 22:59 -0400, Daniel Jacobowitz wrote:

> > The second patch had some points of disagreement, but I think Mark and
> > I more or less agreed on the first one before I ran out of time to work
> > on it (I'll be back real soon, hopefully next week, to those), and the
> > third could probably be gotten into acceptable shape readily once the
> > first is in.
> 
> OK, I get it.
> 
> And actually, the 3rd one works pretty well for me by itself
> (with minor tweaking).
> 
> Would you be willing to see it go in that way, just to get 
> something in there to handle the problem?  And put the other
> parts in at your leisure?
> 
> I'll even do it for you.   ;-)

Ping, Daniel?  I was offering to do the work for you, of
isolating and committing the 3rd part of the patch.  This
would stop the infinite backtrace behavior, and would not
be incompatible with what you intend when you get around 
to finishing the work.

Michael

Re: Ping, Re: Infinite backtrace on (eg.) ARM

[Daniel Jacobowitz]

On Thu, Oct 05, 2006 at 02:49:55PM -0700, Michael Snyder wrote:
> Ping, Daniel?  I was offering to do the work for you, of
> isolating and committing the 3rd part of the patch.  This
> would stop the infinite backtrace behavior, and would not
> be incompatible with what you intend when you get around 
> to finishing the work.

Sorry, as you can tell I'm way further backlogged than just to
mid-September in patch response.  Please give me a chance to
settle out the previous patch, and then maybe this can go in
as-is.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Infinite backtrace on (eg.) ARM

[Jim Blandy]

Michael Snyder <Michael.Snyder@palmsource.com> writes:
> A leaf
> function can only be at frame level zero, unles we've made a dummy
> frame on top of it via a target function call.

Or a signal handler.  (Just had to throw that in, having forgotten
them myself in the past.)