gdb stepping

[Leon Pollak]

Yes, I know this.
What looks strange for me, is that although I made "next" - one C-level 
instruction step, BDI has done 5 steps.
I do not think that BDI did this on his own - he did what he was told to do by 
gdb.
And why in this way?

On Sunday, 2 בMarch 2008, Alexandre Constantino wrote:
> I may not have understood you correctly and be instead completely off the
> target over here, but I think you are mixing different things... C code and
> assembly code. If you give a "next" or "step" instruction to GDB it
> executes a high-level language instruction.
>
> In your example:
> IdleTaskCycles++;
> corresponds to 5 assembly instructions.
> GDB sees 1 high-level instruction while BDI sees 5 assembly lines.
>
> You can also use GDB in assembly mode and get the same low-level view than
> in BDI. To step one assembly instruction use "si" (step instruction).
>
> On Sunday 02 March 2008, Leon Pollak wrote:
> > Hello, all.
> >
> > As the question may be a bit off-topic, I ask your pardon ahead.
> > But it seems tome that this may be interesting to many embedded
> > programmers.
> >
> > Anyway, I am using the BDI2000  device for COP interface to the target
> > and it has additional option to see what is happening via the telnet
> > interface. Using this interface I noticed the following:
> >
> > The simplest operator IdleTaskCycles++ is translated by compiler into 5
> > assembler comands (with -O0):
> >
> > 0x0002b4cc  _Thread_Idle_body+24    lis     r9,15
> > 0x0002b4d0  _Thread_Idle_body+28    lwz     r9,-15912(r9)
> > 0x0002b4d4  _Thread_Idle_body+32    addi    r0,r9,1
> > 0x0002b4d8  _Thread_Idle_body+36    lis     r9,15
> > 0x0002b4dc  _Thread_Idle_body+40    stw     r0,-15912(r9)
> >
> > OK. Now, when, standing on this line (IdleTaskCycles++) I ask the gdp to
> > do "next" command, it does it as required, but the BDI shows me that it
> > has done 5 step commands!
> > The same is with "step" command, which seems obvious.
> > OK, now I put a break point on the next line - one start and one stop,
> > and the result much faster.
> >
> > Assuming that most of us work with some kind of remote connection, you
> > understand that this takes 5 times slower to do a step!
> >
> > What is the catch here? Why do the gdb uses such a strange technique?
> >
> > Thanks.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users