Target Dependent Backtrace Termination

Target Dependent Backtrace Termination

[Robert Norton]

Hi,
 
Our target specifies in the ABI that frames should form a null
terminated back chain something like:
 
Address     Contents
x:          0 
...           \ Frame of thread's  
y:          x / entry function
...           \ Frame of thread's
z:          y / level 1 function
...
 
So in principal it's not too hard for my target dependent code (i.e.
unwind_this_id) to tell when a backtrace should not proceed any further.
The problem I have is in trying to communicate this to the rest of GDB.
My first approach was to detect when unwind_this_id is passed a
next_frame which is the outermost frame and not return the frame_id in
this case, indicating failure. Unfortunately this caused the backtrace
to go one too far! Looking at some other ports it seems that the
solution is to return the null frame id for the outermost frame thus
causing get_prev_frame_1 to return null and terminating the backtrace.
But this means that the outermost frame doesn't haven't a valid frame
id! Won't this cause problems? Am I missing something rather
fundamental?
 
From what I can see all of the checks on frame validity in
get_prev_frame* are performed on this_frame which, in the case of the
outermost frame, is a valid frame and yet we want it to return null for
the previous frame of the outermost frame. How can this work?  Perhaps I
am confused on the meanings of 'this', 'prev' and 'next' (though I
thought I had this nailed down by now)?
 
Robert

P.S. Sorry if this is a duplicate post, my last one didn't seem to get
through.

Re: Target Dependent Backtrace Termination

[Daniel Jacobowitz]

On Tue, Jun 12, 2007 at 02:23:11AM -0700, Robert Norton wrote:
> to go one too far! Looking at some other ports it seems that the
> solution is to return the null frame id for the outermost frame thus
> causing get_prev_frame_1 to return null and terminating the backtrace.

Right.

> But this means that the outermost frame doesn't haven't a valid frame
> id! Won't this cause problems? Am I missing something rather
> fundamental?

Also right.  We've been talking on and off about changing this, so
that an unwinder can indicate "this is marked as the last frame"
separately from "I don't know what this frame's ID is".  If we manage
to do that, I hope we can require all frames to have a valid ID.
No one's done it yet, though.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Target Dependent Backtrace Termination

[Robert Norton]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz
> Sent: 12 June 2007 12:22
> To: Robert Norton
> Cc: gdb@sourceware.org
> Subject: Re: Target Dependent Backtrace Termination
> 
> On Tue, Jun 12, 2007 at 02:23:11AM -0700, Robert Norton wrote:
> > to go one too far! Looking at some other ports it seems that the
> > solution is to return the null frame id for the outermost frame thus
> > causing get_prev_frame_1 to return null and terminating the 
> backtrace.
> 
> Right.

OK. Thanks for the response. I just assumed I must be doing something
wrong since it is an anomaly in what is otherwise a relatively clean
API!
 
> > But this means that the outermost frame doesn't haven't a 
> valid frame
> > id! Won't this cause problems? Am I missing something rather
> > fundamental?
> 
> Also right.  We've been talking on and off about changing this, so
> that an unwinder can indicate "this is marked as the last frame"
> separately from "I don't know what this frame's ID is".  If we manage
> to do that, I hope we can require all frames to have a valid ID.
> No one's done it yet, though.

I think this would be a good idea. I was certainly confused for a while
because of this, and given the recent discussion on this list about the
importance of unique frame IDs not having any for the outermost frame
seems like a bad idea. If you're not keen to add a field to struct
frame_id or change the signature of frame_this_id, perhaps
get_prev_frame_1 could be more eager about getting the frame id for the
prev frame then if it turns out to be null return null to indicate no
previous frame? This is how I assumed things would work given the
current interface.

Cheers,

Robert
 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 
> 

Re: Target Dependent Backtrace Termination

[Daniel Jacobowitz]

On Tue, Jun 12, 2007 at 04:56:57AM -0700, Robert Norton wrote:
> I think this would be a good idea. I was certainly confused for a while
> because of this, and given the recent discussion on this list about the
> importance of unique frame IDs not having any for the outermost frame
> seems like a bad idea. If you're not keen to add a field to struct
> frame_id or change the signature of frame_this_id, perhaps
> get_prev_frame_1 could be more eager about getting the frame id for the
> prev frame then if it turns out to be null return null to indicate no
> previous frame? This is how I assumed things would work given the
> current interface.

No, I think it would be wiser to do one of the other two ideas you
mentioned.  Minimizing unwinding is the central tenet of our current
design, and it seems to work well (though we have room to do it
better).

-- 
Daniel Jacobowitz
CodeSourcery