On Sat, May 8, 2010 at 8:36 AM, Mitch Frazier <[email protected]> wrote: > I'm using openocd (0.40) on a netx50 CPU (an ARM966E-S). > > When I use software breakpoints and I set a breakpoint with gdb I then > get a "false" breakpoint in some library initialization code before > hitting the breakpoint that I actually set. The "false" breakpoint > always occurs at the same address, in my case at 0x8006702e, although > the address is not relevant. The debugger shows: > > 0x8006702e <libfunction+90>: b.n 0x80067272 <libfunction+670> > > The data at 0x8006702c (word that includes 0x8006702e is: 0xE120D900. > Perhaps coincidentally or perhaps not, the software breakpoint value > that openocd inserts (0xE1200070) starts with the same 2 bytes. A dump > of the ARM registers is included at the end of the email. > > During testing I've discovered the following "workarounds": > > - If I single step over the "false" breakpoint and then continue, the > program runs and > I get to the breakpoint that I set. > - If I include "gdb_breakpoint_override hard" in my openocd config file > then I don't get > the false breakpoint and I arrive at the breakpoint that I set and > everything works fine > (except that I'm limited to 2 breakpoints). > - And of course, if I just don't set any breakpoints then the debugger > runs the code > without producing the "false" breakpoint. >
how about the endianess used in your cfg? I just found/fixed a similar bug on an ARM926ej-s bigendian system. and I take the same 'workaround' as you did before I fix it. > Does this seem like an openocd bug or some kind of ARM processor related > problem? > shouldn't be ARM's problem, they were sold out everywhere for many years -- FIXME if it is wrong. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
