Unneeded displaced single stepping causes issues: Performance drop and range stepping killer

Raphael Zulliger zulliger@indel.ch
Wed Apr 24 06:58:00 GMT 2013

On 04/24/2013 04:24 AM, Yao Qi wrote:
> Considering your goal, I suggest that please make range stepping on,
> and probably turn displaced stepping off.
I'm definitely going to turn range stepping on, as we benefit much from it!

Turning off displaced stepping is not an option for our system 
real-time embedded), as it would mean that other threads could miss 
(which got temporarily removed by the single-stepping mechanism)
> If you are using breakpoint
> with conditions, please 'set breakpoint condition-evaluation target'
> (it requires your remote stub support condition evaluation), it will
> improve the performance to some extent.
> On the other hand, we have a local patch to prefer range stepping to
> software single step:
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index cbc11f7..b606384 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -1824,7 +1824,9 @@ a command like `return' or `jump' to continue execution."));
>       }
>     /* Do we need to do it the hard way, w/temp breakpoints?  */
> -  else if (step)
> +  else if (step
> +	   && !(target supports range stepping () /* undefined */
>       step = maybe_software_singlestep (gdbarch, pc);
>     /* Currently, our software single-step implementation leads to different
Unfortunately, this doesn't help. In my use-case in which "unwanted" 
single-stepping happens, we already took the "if" path of the "else if" 
mentioning here :-(.
> target_supports_range_stepping can be hacked to 1 in your case.  It
> helps in your case that the remote stub is able to do single step
> while the GDB side uses software single step.
I don't understand this. (Maybe I already misunderstood the intention of
the small patch above?).
We use our own gdbstub implementation (completely independent from
gdbserver). In order to try the range stepping patches, I already extended
our stub to return "vCont;c;C;s;S;t;r"
> My range stepping series didn't include this patch above, because it is a
> step-2" patch series.  My plan is to draft and post the "step-2"
> patches series after getting some comments on range stepping patches.
> I'd like to get the existing patches reviewed and committed first, and the
> start to work on "step-2" patches.
> B.T.W, we are looking for the opportunities to improve the performance
> of remote debugging, "target-side condition evaluation" and
> "range stepping" are of this kind.  If you know some cases are extremely
> slow, please let us know.
- "target-side condition evaluation" is certainly something we'd love to
have in our system... on the other side, using conditional breakpoints
is not the main use case when debugging our system so far. (Probably
because we didn't have that feature at all in the past).
- There's something I hope we could improve (but I haven't looked
into the code yet): When GDB receives a stop reply, it issues many "memory
reads". Sometimes it read consecutive memory by multiple RSP packages.
Sometime it even reads the same memory region twice. The following
shows a typical sequence after 1 single-step (or range step) on our system

Sending packet: $vCont;r49c38,49c40:p1.dca318#1f...Packet received: OK
   Notification received: 
Sending packet: $vStopped#55...Packet received: OK
Sending packet: $mdce0c0,40#ec...Packet received: 
Sending packet: $mdce0c0,40#ec...Packet received: 
Sending packet: $mdce100,40#ba...Packet received: 
Sending packet: $mdce340,40#c0...Packet received: 
Sending packet: $mdce380,40#c4...Packet received: 
Sending packet: $mdce3c0,40#ef...Packet received: 
Sending packet: $mdce400,40#bd...Packet received: 
Sending packet: $mdce480,40#c5...Packet received: 
Sending packet: $mdce4c0,40#f0...Packet received: 
Sending packet: $mdce780,40#c8...Packet received: 

(Note that this comes from a slightly patched gdb. But I'm pretty sure 
theses patches shouldn't have any influence on these memory reads)


More information about the Gdb mailing list