Odtnhj

I am running a C software on an ARM IP (module name is ARM926EJS) provided by Synopsis, and the entire tool I am using is Platform Architect also by Synopsis (based on TLM simulator, the hardware part is implemented in SystemC).

I received from my hardware module an address that the software is not supposed to access. Hardware modules cannot see the information of the software (or I may just not know), so I usually attach arm-none-eabi-gdb to the ARM IP during simulation to debug the software.

I have to check, but I believe that the ARM IP I am using does not support hardware watchpoint (using only one hardware watchpoint returns "too many hardware watchpoints"). I am trying software watchpoint by typing

 set can-use-hw-watchpoints 0

I tried to see when the software accesses the strange address by typing

 watch *(int*)(0x2056604+0xd0000000)

which the number is the address that I am receiving on the hardware. However, the program freezes, and the interrupt on gdb does not even work, I have to stop the simulation and delete the watchpoint to go on.

Strangely though, rwatch works correctly (although the problem persists since the address is accessed as "write"). It really would be beneficial to see which point in the software has caused the access to address 0x2056604+0xd0000000, but as watchpoints are not working for me, are there alternative ways to break on such access? Or is there a way to fix the freezing problem on software watchpoints?

Additional Note) I also tried to pause simulation on the memory access, then view the stack frame of the software. The software has strange stack and the gdb tells me that the stack is possibly corrupted. Output is the following..

 #0 0x00002bf0 in ?? ()
 #1 0x00001b94 in ?? ()
 #2 0x00001b94 in ?? ()
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)