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

[Raphael Zulliger <zulliger at indel dot ch>]

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 
(multithreaded
real-time embedded), as it would mean that other threads could miss 
breakpoints
(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 */
> +		&& THREAD_WITHIN_SINGLE_STEP_RANGE (tp, pc)))
>       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" 
displaced
single-stepping happens, we already took the "if" path of the "else if" 
you're
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: 
Stop:T05thread:p1.dca318;0:00000002;1:00dce078;2:00dca318;3:00dce09c;4:d8434b16;5:005a21b4;6:00dce098;7:00000002;8:00000005;9:000002e4;a:d8434b16;b:00dce050;c:00000000;d:f5ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;12:0068e9f0;13:001dd964;14:00000000;15:00000000;16:0069c3d8;17:00000000;18:00000037;19:00000000;1a:00000032;1b:00e6b4c0;1c:00087e48;1d:00ecd2d0;1e:00ecdb98;1f:00dce078;20:00000003d8434b16;21:3ff199999999999a;22:3ff199999999999a;23:0000000000000000;24:0000000000000000;25:0000000000000000;26:0000000000000000;27:0000000000000000;28:0000000000000000;29:0000000000000000;2a:0000000000000000;2b:0000000000000000;2c:401900a3d70a3d71;2d:3ff199999999999a;2e:0000000000000000;2f:0000000000000000;30:0000000000000000;31:0000000000000000;32:0000000000000000;33:0000000000000000;34:0000000000000000;35:0000000000000000;36:0000000000000000;37:0000000000000000;38:0000000000000000;39:0000000000000000;3a:0000000000000000;3b:0000000000000000;3c:0000000000000000;3d:0000000000000000;3e:0000000000000000;3f:0000000000000000;46:efbeadde;40:00049c40;41:0008a030;42:20000008;43:00049d58;44:00000000;45:00000000;
Sending packet: $vStopped#55...Packet received: OK
Sending packet: $mdce0c0,40#ec...Packet received: 
00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c0000002020000000100dce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100
Sending packet: $mdce0c0,40#ec...Packet received: 
00e6b488000020300000a03000dce0d000dce0e8004a066800e6b4c0000002020000000100dce0e800dce100004d0aa800dce45000ecd90000b36b7400dce100
Sending packet: $mdce100,40#ba...Packet received: 
00dce3780008148800ecd9c400000037000000000000003200e6b4c000087e4800dce35800dce35800dce2f800dce154001c748c00dce4008080808064630000
Sending packet: $mdce340,40#c0...Packet received: 
0000a030000814580000000400dce3500000000000dce35800ecd2d000dce45000dce40000dce36800dce39000ecd2d000ecdb9800dce37800dce390004cbc38
Sending packet: $mdce380,40#c4...Packet received: 
00ecdb9800dce3ac00dce3a000dce39000dce3f8000830e8ffffffff0000000100dce45000ecdb9801dce3b800ecdb9800ecd9280000000800ecd97000ecd970
Sending packet: $mdce3c0,40#ef...Packet received: 
00ecdb7000ecd93400ecd97400ecd97000ecdb7000ecd93400e6b6a800dce45000dce40000e6b4c000dce4f40000003500e6b4c000dce3f800dce42800087ec8
Sending packet: $mdce400,40#bd...Packet received: 
00e6b4c000dce4f40063d47800dce44c00dce4f400dce45000e6b4c000dce44c00e6b4c000dce42800dce4a8000847b000ecce3c00ecd34c00ecd38800000000
Sending packet: $mdce480,40#c5...Packet received: 
00e6b4c000dce4f4000000350000000000dce4a800377a5000000000000000000000006400dce4a800dce4c00008522800dce4d000dce4f40000006400dce4c0
Sending packet: $mdce4c0,40#f0...Packet received: 
00dce7980007ec586464646464646464005cc40000e6b4c000dce4f06464646400ecc92064646464005c481800dce4f000dce508005ccb0000eccdb800eccdf0
Sending packet: $mdce780,40#c8...Packet received: 
00dce79800dce6d000dca31800e6b4c00000006400dce79800dce7b00007e89c00dca31800ecc7f80000006400dce7b000dcede80034288400dce99000dce930

(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)

Thanks,
Raphael