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.

Does this seem like an openocd bug or some kind of ARM processor related
problem?



The ARM registers after the "false" breakpoint is set are:

 ===== ARM registers
(0) r0 (/32): 0x00000000 (dirty)
(1) r1 (/32): 0x00000000 (dirty)
(2) r2 (/32): 0x0000C008 (dirty)
(3) r3 (/32): 0x0000C007
(4) r4 (/32): 0x00000000
(5) r5 (/32): 0x800C64C8
(6) r6 (/32): 0x800C64CC
(7) r7 (/32): 0x800C64D0
(8) r8 (/32): 0x80125FB8
(9) r9 (/32): 0x801254F8
(10) r10 (/32): 0x800C64C4
(11) r11 (/32): 0x80125FB8
(12) r12 (/32): 0x800B2FAD
(13) sp_usr (/32): 0x80006E70
(14) lr_usr (/32): 0x800B1321
(15) pc (/32): 0x8006702E (dirty)
(16) r8_fiq (/32)
(17) r9_fiq (/32)
(18) r10_fiq (/32)
(19) r11_fiq (/32)
(20) r12_fiq (/32)
(21) sp_fiq (/32)
(22) lr_fiq (/32)
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32)
(26) lr_svc (/32)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0x2000003F
(32) spsr_fiq (/32)
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
===== EmbeddedICE registers
(37) debug_ctrl (/6): 0x05
(38) debug_status (/10)
(39) comms_ctrl (/6)
(40) comms_data (/32)
(41) watch_0_addr_value (/32): 0x10000018
(42) watch_0_addr_mask (/32): 0xFFFFFFFF
(43) watch_0_data_value (/32): 0xE1200070
(44) watch_0_data_mask (/32): 0x00000000
(45) watch_0_control_value (/9): 0x0000
(46) watch_0_control_mask (/8): 0xF7
(47) watch_1_addr_value (/32)
(48) watch_1_addr_mask (/32)
(49) watch_1_data_value (/32)
(50) watch_1_data_mask (/32)
(51) watch_1_control_value (/9)
(52) watch_1_control_mask (/8)
(53) vector_catch (/8)
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to