On 05/09/2010 08:52 AM, Ryan J M wrote: > 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. >
My target is little endian and the config is set to little endian. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
