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

[Raphael Zulliger <zulliger at indel dot ch>]

Hi

I've been playing around with the 'range stepping' patch set. (Thanks 
for that great feature!) Thereby I encountered the following behavior:
    Targets, having a 'gdbarch->software_single_step' function set, are 
always using displaced single stepping even when "normal" single 
stepping would be sufficient. (sure, displaced single-stepping may have 
the advantage of less breakpoint hits by foreign task, but...)
While this is not a problem as such, it may be sub-optimal because:
    Issue a) At least on extended-remote ppc target displaced single 
stepping causes much more RSP traffic
    Issue b) It renders 'range stepping' useless

Let me explain Issue a)
Not sure whether this statement is correct for all platform out there, 
but on my PPC603/EABI extended remote target, the difference between 
non- vs. displaced single stepping is quite big.

        (gdb) set displaced-stepping 0
        (gdb) si
        Sending packet: $m832d0,4#fe...Packet received: 9421ffc8
        Sending packet: $vCont;s:p1.dca118#83...Packet received: OK
          Notification received:
Stop:T05thread:p1.dca118;0:00dcdea0;1:00dcde40;2:00dca118;3:00dcdea4;4:00dcdea0;5:00000142;6:00dcde68;7:00000002;8:00000005;9:00dcdea4;a:00579e90;b:00ed4b34;c:00000000;d:f7ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;12:0068e738;13:001dd964;14:00000000;15:00000000;16:0069c120;17:00000000;18:00000037;19:00000000;1a:00000032;1b:00e6b2c0;1c:00087e48;1d:00ed12a0;1e:00ed1b68;1f:00dcde78;20:00000006347fd013;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:000832d4;41:0008a030;42:20000004;43:00049cd0;44:00000000;45:00000000;
        Sending packet: $vStopped#55...Packet received: OK
        0x000832d4    20    SourceLine::SourceLine( const std::string 
&fileName,

versus:

        (gdb) set displaced-stepping 1
        (gdb) si
        Sending packet: $m1508,4#9b...Packet received: 3c000058
        Sending packet: $m832d4,4#02...Packet received: 7c0802a6
        Sending packet: $X1508,0:#bc...Packet received:
        binary downloading NOT supported by target
        Sending packet: $M1508,4:7c0802a6#b0...Packet received: OK
        Sending packet: $g#67...Packet received: 
00dcdea000dcde4000dca11800dcdea400dcdea00000014200dcde68000000020000000500dcdea400579e9000ed4b3400000000f7ffffff00000357f101000000000000fff716580068e738001dd96400000000000000000069c1200000000000000037000000000000003200e6b2c000087e4800ed12a000ed1b6800dcde7800000006347fd0133ff199999999999a3ff199999999999a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000401900a3d70a3d713ff199999999999a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000832d40008a0302000000400049cd00000000000000000efbeadde
        Sending packet: $P40=00001508#7f...Packet received: OK
        Packet P (set-register) is supported
        Sending packet: $vCont;s:p1.dca118#83...Packet received: OK
          Notification received: 
Stop:T05thread:p1.dca118;0:00049cd0;1:00dcde40;2:00dca118;3:00dcdea4;4:00dcdea0;5:00000142;6:00dcde68;7:00000002;8:00000005;9:00dcdea4;a:00579e90;b:00ed4b34;c:00000000;d:f7ffffff;e:00000357;f:f1010000;10:00000000;11:fff71658;12:0068e738;13:001dd964;14:00000000;15:00000000;16:0069c120;17:00000000;18:00000037;19:00000000;1a:00000032;1b:00e6b2c0;1c:00087e48;1d:00ed12a0;1e:00ed1b68;1f:00dcde78;20:00000006347fd013;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:0000150c;41:0008a030;42:20000004;43:00049cd0;44:00000000;45:00000000;
        Sending packet: $vStopped#55...Packet received: OK
        Sending packet: $M1508,4:3c000058#78...Packet received: OK
        Sending packet: $P40=000832d8#ba...Packet received: OK
        0x000832d8    20    SourceLine::SourceLine( const std::string 
&fileName,
        (gdb)

Issue b)
According to my current understanding (please correct me if I'm wrong): 
Range stepping decides whether to send a 'vCont;r' package by comparing 
the current program counter with the range that needs to be executed 
(control.step_range_start and control.step_range_end). Using displaced 
single stepping means that the program counter is, by definition, always 
outside the range that needs to be single stepped and thus 'range 
stepping' will never be used.

What causes the problem?
The following statement (from infrun.c, resume(), git master) decides 
whether to use displaced single stepping or not:
  if (use_displaced_stepping (gdbarch)
      && (tp->control.trap_expected
      || (step && gdbarch_software_single_step_p (gdbarch)))
      && sig == GDB_SIGNAL_0
      && !current_inferior ()->waiting_for_vfork_done)

According to my experiments:
    - Using gdb/gdbserver on x86/64, that statement is 'true' when we 
step over a breakpoint, but is 'false' otherwise ->range stepping is 
used when possible
    - Using extended remote to ppc603/EABI embedded system, that 
statement is always 'true' when we step because 
'gdbarch_software_single_step_p' returns 'true' ->range stepping is 
never used
    - When patching GDB so that 'gdbarch->software_single_step = NULL', 
then the behavior is like on x86/64 and thus 'range stepping' works 
->range stepping is used when possible


Finally, my request: Could someone with more insight into GDB internals 
please decide whether we have to fix something here and if yes, how? Or, 
in case that my conclusions are wrong, could you help me to really 
understand the problem? (FYI: My ultimate goal is to speedup remote 
debugging for our ppc603/EABI target.)

Thanks,
Raphael