-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Software breakpoint has been overwritten outside of debugger" warning when debugging linux #23
Comments
Hi, I've tried to reproduce this on AXS101, but the problem doesn't happen to me - there is no stray BRK in the instr_service and From the top of my head I don't know what place in OpenOCD could cause this issue, although it is clear that kernel flushing cache and OpenOCD doing so might interfere with each other, but it doesn't seem like this would be the case in this function. Also if we look at the log messages you have, there is some discrepancy. OpenOCD expects a BRK at 0x802be9d4, but instead gets 0x0001000; yet when doing disassembly and reading same memory location - BRK is there. So it looks like some issue when first reading this memory location, and because OpenOCD cannot find it's breakpoint there, it leaves it as-is, thus it becomes permanent. It might be some JTAG issue, because I've seen some problems with its behaviour. Could you please try a few things to see if they work:
|
I'm already running the JTAG at 1MHz. running it any slower would make testing impractical. I do notice unexplained phenomenon with the JTAG at higher frequencies, but 1M seems just fine. I tried point (4), and the openocd output is in this gist issuing
If there's nothing informative in the openocd log above, I could try to find an AXS101 and reproduce the issue there. Right now I'm running this on a emulation FPGA. |
Log doesn't really help, because as I now see it doesn't record what are the actual values that are read from memory, because it would blow up the size of log file. It would be nice if you could check this on AXS101, because if it can be reproduced on it, then I'd have an easier time troubleshooting this problem. I have a few more questions as well:
While looking at the log, I've noted an interesting thing at the end.
So when Openocd first reads the memory, it flushes D$ as it should. For this it reads 0x48 DC_CTRL, sets a bit there, flushes cache, restores DC_CTRL to original value of 0x82. When a second request comes in and it invalides memory (because it was assumed that that OpenOCD would write an original content of memory to replace breakpoint). First it invalidates I$ by writing to 0x10 IC_IVIL, then it reads DC_CTRL again, but it reads value 0x1 instead of a 0x82 which used to be there. So eventually OpenOCD writes 0x1 to DC_CTRL, completely disabling D$ afterwards. So once again operation on cache yields a 0x1 result for the following operation. So I think you need to try to try with disabled caches. |
I tactically acquired a AXS101, so I will try to see if I can reproduce on it. |
When hitting a breakpoint while debugging a linux kernel, on an ARCCompact target, when a breakpoint is hit, the next instruction is replaced by a 'brk'.
OpenOCD prints the following warning:
Examining the disassembly shows a 'brk' instruction has been inserted:
From this point, trying to step or continue will not work, as the CPU continuously hits the 'brk':
The text was updated successfully, but these errors were encountered: