RE: Target Dependent Backtrace Termination

["Robert Norton" <rnorton@broadcom.com>]

> -----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
> 
>