On Wed, Sep 15, 2010 at 12:22 AM, Nived <nive...@gmail.com> wrote:
> Hi,
> I have been using software breakpoints to debug, i was using an older
> version of OpenOCD and only recently upgraded to a higher version. I can
> confirm that the issue exists for software breakpoints, how do i check the
> hardware breakpoints ?
Google for the differences.
Basically, when you set SW ("normal", the one GDB sets by default)
breakpoint, GDB will temporarely replace instruction at that memory
address in RAM with special bkpt instruction (architecture dependent)
and save somewhere original instruction so it can restore it lately
(when you delete breakpoint).
HW breakpoints work, well, with the hardware support. That is, if your
core supports them. No instruction is replaced in RAM, but HW is
issuing break when observed memory location is addressed. They are
more powerful, but limited in number. For example, I have them 2 for
ARM946E.
To set a HW breakpoint in GDB insted of "break" use hbreak, like this :
(gdb) hbreak <your_symbol>
Read a help :
(gdb) help hbreak
> Also i tried setting pc to a higher value, but it says there is no such
> variable pc when i try setting it. Could you please explain how to do this
> in a little more detail ?.
PC is a program counter register. Variables in GDB should be prefixed
by dollar sign. It is $pc for me, but observe your registers with :
(gdb) info registers
and see, maybe it is called differently for your architecture (though I doubt).
> Does deleting the break point after it hits work for you?
When I delete I can see that breakpoint instruction is replaced back
in memory by original instruction. I suspect that it is not replaced
in I$, because that part of the code is not implemented in OpenOCD for
my core. But I flushed I$, so we can pretend that it is well replaced.
But all of this does not prevent program to hit the same breakpoint on
every 'n' or 'c'. So, the problem persist.
As I explained before, we should be able to do 'n' or 'c' without
deleting breakpoint, so I would put a side I$ coherency for the
moment. I'd say that problem is somewhere else - probably in a way
that OpenOCD handles the SW interrupts provoked by the breakpoints.
Try with HW breakpoints, and report what you saw.
Also, it would be good if you can try the telnet OpenOCD monitor, so
that we confirm that the same problem happens there, and that it is
not a buggy GDB. I already tried and noted the same behavior as with
GDB, so I can say with high probability that this is a bug in OpenOCD.
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
