gdb stepping

[Chris Johns]

Leon Pollak wrote:
> 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 see little difference between the step and next in terms of GDB so they are
both important.

> OK. But why not to set a break point at that next line at the beginning and 
> run till it is hit?

Because GDB cannot read C (nor C++, Fortran, Ada, Java etc). Take this example:

   switch (foo())
   {
      case 1:
       break;
      case 3:
       break;

     // many many cases
   }

Which line do you set the breakpoint on or do you block every path ? Setting
break points is not fast and uses memory in GDB and the GDB server then you
need to clean up after.

What about:

  10  if (foo() == true) do_something_here(); else
  11   do_something_else;
  12  next_line();

A next on line 10 should place you on 11 or 12 depending on the result of foo.
Again you need to locate all "next paths" and set break points.

These are simple examples. I am sure more complex ones can be found.

> Thank you for confirming my experimental conclusions - I saw this working this 
> way and guessed...:-)

No problem.

It works this way to stop a stepi jumping to an interrupt. QEMU for the i386
does not mask interrupts when using GDB and it is a pain. Every time you hit a
break point then step you end up in an interrupt. You cannot step any code.
The current way things work is the best that can be done. If you have hit a
break point you have already given up on getting to what ever interrupt in a
timely manner.

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

I do not see a performance issue with the Coldfire BDM GDB server
implementation. If you have a performance issue I suggest you raise it with
the makers of your GDB server device.

If you have any positive suggestions on improving GDB's performance I am sure
  they would be most welcome on the GDB lists.

Regards
Chris