This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding -file-list-exec-source-file command to GDB/MI


On Mon, Mar 31, 2003 at 01:52:35PM -0500, Andrew Cagney wrote:

> >> > The other difference is the addition of FP here -- our UI uses the
> >> > PC and FP to uniquely identify stack frames
> > 
> >> 
> >> That doesn't work.  The MI needs to be updated so that it uses frame 
> >> ID's when identifying frames.
> > 
> > 
> > Uh, we have a bit of an existance proof that it does--in the form
> > of a PB+GDB that have been shipping like this for over a year.
> 
> Unfortunatly, that doesn't mean that it works:
> 
> - it doesn't handle architectures with multiple stacks (ia64)
> - it relies on $fp being constant through out the lifetime of the frame 
> (including the prologue) and that is definitly not true
> - I suspect it is also making similar assumptions about $pc, it should 
> be using func.


Ah, now I see.  You didn't mean "That doesn't work", you meant "That
doesn't work generally".

#1 doesn't apply to us at Apple.  #2 is a real problem - although
the failure mode is that the UI re-fetches the stack, so it's not
too traumatic.  And because it only needs to re-fetch the 0th frame,
it is fast.  And you'll have the same problem with varobj's being
deleted when your FP moves IIRC.  

As for #3, I don't understand why the PC won't remain constant for
a frame other than the 0th, but you're familiar with far more
architectures than me.  Obviously the currently executing frame
will have a changing PC, but the frames higher up on the stack
should stay constant unless they've executed some more.


Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]