This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Instrcutions that must not be stepped.
- From: Daniel Jacobowitz <drow at false dot org>
- To: John Yates <jyates at netezza dot com>
- Cc: PAUL GILLIAM <pgilliam at us dot ibm dot com>, gdb at sources dot redhat dot com
- Date: Fri, 9 Jun 2006 10:12:10 -0400
- Subject: Re: Instrcutions that must not be stepped.
- References: <4D87F853B8020F4888896B1507DC0F090268F0@mail2.netezza.com>
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