Re: [rfa/mips] Stop backtraces when we've lost the PC

[Daniel Jacobowitz <drow@false.org>]

On Thu, Mar 11, 2004 at 06:47:04PM -0500, Andrew Cagney wrote:
> >On Thu, Mar 11, 2004 at 03:51:11PM -0500, Andrew Cagney wrote:
> >
> >>>>>I hypothesize that if two consecutive frames, regardless of their type,
> >>>>>claim to save the PC register at the same location, then unwinding is
> >>>>>hosed.
> >>
> >>>
> >>>It would need to do a deep analysis of the location (think about a 
> >>>register window architecture), hence I don't know that there's that much 
> >>>cost benefit.
> 
> >>> Something simpler such as a list of functions known to
> >>>terminate the stack might be more useful.
> >
> >
> >Er, no.  frame_unwind_register tells us where, relative to the current
> >machine state, the register is saved.  If it returns lval_register and
> >real_regnum == O7_REGNUM, then that means it leaves in
> >read_register(O7_REGNUM) at this moment, not that it did at some point
> >in the past.  Isn't that the point of the recursive unwinder?
> 
> "Er, no". to which part?  I'll assume the first half of the first half.
> 
> I suspect you're violently agreeing with me here - you're describing 
> what I ment by a deep analysis of the location - tracking things all the 
> way back to where in the inferior the value is.   The architecture 
> vector will need to be changed, the existing function deprecated, and 
> new methods implemented.  The introduction of "struct location" (or 
> whatever) would then see it changed again. Given it is all for a 
> marginal edge case (and to cover up breakage in glibc), I don't see any 
> cost benefit in doing this.

OK.  It was just a thought :)  It seems reasonable that whatever kind
of location frame_unwind_register returns (which you're right, is
likely to change) could naturally be returned by frame_unwind_pc also.
But it would require playing with the interfaces pretty severely, so
I'll just table the idea unless I run into this again somewhere else.

> I think a more useful mechanism is for there to be a table of "start" 
> functions that the user could manipulate (but would default to values 
> specified by the OSABI).

I'm not sure how useful that would really be; we seem to handle the
entry points OK at the moment.  And it couldn't be used for this case
since we do want to backtrace past clone in some circumstances.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer