gdb single stepping takes ages

gdb single stepping takes ages

[Tim Sander]

Hi

I am currently using openocd as a gdbserver backend for debugging  an embedded 
target with gdb 7.7. When i want to step over a single line with -exec-next:

for(int a=0; a<1000000;a++){ };

the time taken for the step is linear to the maximum count number and takes in 
my setup about 1 second for one increment of a. Setting a temp breakpoint in 
the next line and continuing works much faster.

So is there a way improve the stepping speed in such situations?

Best regards
Tim

Re: gdb single stepping takes ages

[Tim Sander]

Hi 

> I am currently using openocd as a gdbserver backend for debugging  an
> embedded target with gdb 7.7. When i want to step over a single line with
> -exec-next:
> 
> for(int a=0; a<1000000;a++){ };
> 
> the time taken for the step is linear to the maximum count number and takes
> in my setup about 1 second for one increment of a. Setting a temp
> breakpoint in the next line and continuing works much faster.
> 
> So is there a way improve the stepping speed in such situations?
> 
> Best regards
> Tim

Just after sending the mail recognized that the thread: "Remote Debugging with 
NEXT Command" touches a similar (the same?) issue. A solution mentioned was 
range checking. But in the openocd case it seems already enabled:
show range-stepping
Debugger's willingness to use range stepping is on.

Best regards
Tim

Re: gdb single stepping takes ages

[Mark Kettenis]

> From: Tim Sander <tim@krieglstein.org>
> Date: Wed, 18 Jun 2014 09:24:04 +0200
> 
> Hi
> 
> I am currently using openocd as a gdbserver backend for debugging an
> embedded target with gdb 7.7. When i want to step over a single line
> with -exec-next:
> 
> for(int a=0; a<1000000;a++){ };
> 
> the time taken for the step is linear to the maximum count number and takes in 
> my setup about 1 second for one increment of a. Setting a temp breakpoint in 
> the next line and continuing works much faster.
> 
> So is there a way improve the stepping speed in such situations?

Use a native debugger.

Re: gdb single stepping takes ages

[Luis Machado]

On 06/18/2014 08:24 AM, Tim Sander wrote:
> Hi
>
> I am currently using openocd as a gdbserver backend for debugging  an embedded
> target with gdb 7.7. When i want to step over a single line with -exec-next:
>
> for(int a=0; a<1000000;a++){ };
>
> the time taken for the step is linear to the maximum count number and takes in
> my setup about 1 second for one increment of a. Setting a temp breakpoint in
> the next line and continuing works much faster.
>
> So is there a way improve the stepping speed in such situations?
>
> Best regards
> Tim
>
>

In that case i'd use "until <line number>" to skip the loop. Stepping 
through the loop *will* take a long time since GDB instruction-steps its 
way out of there (for reasons explained in the Remote Debugging mail you 
mentioned in the other mail).

Luis

RE: gdb single stepping takes ages

[Agovic, Sanimir]

> Just after sending the mail recognized that the thread: "Remote Debugging with
> NEXT Command" touches a similar (the same?) issue. A solution mentioned was
> range checking. But in the openocd case it seems already enabled:
> show range-stepping
> Debugger's willingness to use range stepping is on.
> 
This command shows the "willingness" not if it is actually enabled:

(gdb) show range-stepping
Debugger's willingness to use range stepping is on.

(gdb) set range-stepping on
warning: Range stepping is not supported by the current target

Imho, it is a bit confusing.

 -Sanimir

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Re: gdb single stepping takes ages

[Yao Qi]

On 06/18/2014 04:14 PM, Tim Sander wrote:
> Just after sending the mail recognized that the thread: "Remote Debugging with 
> NEXT Command" touches a similar (the same?) issue. A solution mentioned was 
> range checking. But in the openocd case it seems already enabled:

range stepping was added to improve the line stepping speed, but remote
stub (openocd in your case) has to support it.

> show range-stepping
> Debugger's willingness to use range stepping is on.

GDB can't do range stepping without stub's support.  This command shows
the willingness of GDB to use range stepping, but if stub doesn't
support, GDB is still unable to do that.  Please check your stub really
supports range stepping.

From the code or rsp level, the remote stub has to claim it supports
range stepping in the reply to vCont? ('r' in the reply), like this:

Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S;t;r

Then, if we type command 'next', GDB will send "vCont;r"

Sending packet: $vCont;r80484cc,80484d7:p1cb0.1cb0;c#16...Packet
received: T0505:38eeffbf;04:c0ebffbf;08:d7840408;thread:p1cb0.1cb0;core:0;

-- 
Yao (齐尧)