Interpretation of GDB-RSP step commands

Hi Folks,

I'm poring over the gdb pdf trying to understand the difference between the s and i commands.

After chatting with a colleague we came up with 2 ideas:

1. i means a single instruction step, and s is an instruction step but step over CALL instructions.


2. i means advance the clock once, i.e. by a single word in a multi-word instruction. And s means a single instruction step.

All comments welcome!


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at Keep up to date with CSR on our technical blog,, CSR people blog,, YouTube,, Facebook,, or follow us on Twitter at
New for 2014, you can now access the wide range of products powered by aptX at

Sorry, I should have been more direct in this post...

Does anyone actually know the difference in the GDB-RSP i and s commands?

I'd welcome your insight.


Matthew Gardiner wrote:

Hi Matthew,

This link seems to give some details:
Where as: I believe that step should execute one whole machine instruction or one instruction packet depending on the architecture. The S command should step into call instructions, not over. Stepping over anything is a task for the debugger, and is managed by coordinating breakpoints, stepping and continuing. I cant imagine the ā€˜iā€™ command is commonly supported however since I presume it would require very complex and tight coupling between the processor running the stub and the processor being debugged as the clock is not typical accessible. For regular source level debugging this level of control is not typical required. Thanks, Aidan

Thanks Aidan,

Yes, that's what myself and my colleague imagined: i.e. s is a regular "execute next instruction then stop" step, and i somehow advances the clock, possibly stepping within a single multi-word instruction. The reason why I was puzzled, and hence why I reached out, was because I couldn't see any regular (gdb) command-line that would actually make use of this (that is the i packet), given our interpretation.

thanks again

Aidan Dodds wrote: