This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/mips] Stop backtraces when we've lost the PC
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