[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Wed, 05 Mar 2008 09:41:29 +1100
- From: chrisj at rtems.org (Chris Johns)
- Subject: gdb stepping
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
> 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:
// 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.
10 if (foo() == true) do_something_here(); else
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...:-)
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
> 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.