This is the mail archive of the gdb@sourceware.org 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: Instrcutions that must not be stepped.


On Fri, Jun 09, 2006 at 09:49:54AM -0400, John Yates wrote:
> Daniel Jacobowitz writes:
> 
> > Nope.  You'd have to add one.  And, you'd have to be able to tell
> > whether you were in the middle of a GDB-automated step or a user stepi;
> > stepping multiple instructions when the user asked for one is probably
> > just confusing.
> 
> To whom or what?  I would be quite happy if gdb did the right thing
> and output a message to the effect that an atomic sequence was indeed
> treated as atomic.  That is the count of instructions stepped changed
> by one for any number of failed attempts and then one final successful
> execution of the entire atomic sequence.

If we warn about it, then it's not so confusing :-P

There are plenty of other potential issues here.  For instance, we'd
need to check for branches inside the atomic sequence; otherwise we
could completely lose control.

> > Reading the instruction before stepping is going to slow down single
> > stepping.  Is there some other way we can handle this?
> 
> The overhead could be ameliorated by having the status returned from
> a completed single step include an optional assertion that if gdb were
> to step again without altering the pc or the contents of memory at the
> address referenced by the pc then that step would initiate an atomic
> sequence.

There is no way to do this for most targets.  Paul's probably talking
about native PowerPC GDB, not any kind of remote stub.  Even at that
point, I think the performance impact here would be unacceptable; the
repeated single step path is one of the few time-sensitive bits of GDB.

-- 
Daniel Jacobowitz
CodeSourcery


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