gdb stepping

[Leon Pollak]

Thanks a lot to Chris for detailed explanation.


> Leon Pollak wrote:
> > 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?
>
> Yes this is GDB doing this. GDB does not know your code will actually head
> directly to the next line. Consider:
May be I miss something, but in the case of the "next" command, this is not 
interesting for me - I want to arrive to the next line, even in inderect way.


>    i = foo();
>
> A step command will enter and stop in 'foo' and a next command will go the
> next line. Consider something a little more complex:
>
>   i = foo (x == 0 ? bar () : 0);
>
> In the case of a next here, GDB will step each instruction and check the PC
> to see if it is still in the current function range. If it is not because
> 'bar' has been called GDB gets the return address from the stack and sets a
> break point on that location then continues the program. When 'bar' returns
> GDB will step again until 'foo' is called and then repeat the break point
> setting procedure. This continues until GDB sees the next line has been
> reached. 
OK. But why not to set a break point at that next line at the beginning and 
run till it is hit?


> A note to RTEMS users is GDB will use the stepi command to step. Normally
> this does not allow interrupts to occur. A simple piece of code such as:
>    i++;
> will not let an interrupt occur, while a next on:
>    i = foo();
> will. This is because the program will be continued inside foo will allow
> interrupts. The point here is certain race conditions can be masked by GDB
> in certain cases and so you need to think a little about this when
> debugging.
Thank you for confirming my experimental conclusions - I saw this working this 
way and guessed...:-)



Still, the way gdb does "nexting" is not clear to me. And this is obviously 
very time consuming...


> Regards
> Chris
Thanks again.

-- 
Leon