riscv-openocd
riscv-openocd copied to clipboard
riscv
OpenOCD doesn't support FreeBSD?
When I used riscv-openocd to debug my FreeBSD kernel on sifive unmatched board, I found I can't add breakpoints.
This is my issue: https://forums.sifive.com/t/openocd-failed-to-read-memory/5791
In OpenOCD User's Guide pdf, it says:
There is no -rtos for FreeBSD.
Is it true that OpenOCD does not support FreeBSD debugging?
I can debug the Linux using '-rtos linux' in openocd.cfg file.
You shouldn't need any -rtos option for debugging a kernel.
That option is really for doing [RT]OS aware debugging of processes/tasks running on the relevant [RT]OS.
In any case, you seem to be correct - OpenOCD does not currently have any -rtos FreeBSD option but I would have expected that -rtos linux would work with FreeBSD for OS aware debugging?
The memory access issue that you mention was fixed a long time ago but you may have to build OpenOCD yourself from this repo in order to benefit from it.
Given that riscv-openocd is still being changed/maintained frequently, in my opinion, it's often best to build the latest version from this repo in order to benefit from all recent changes, bugfixes etc.
I used the latest version of riscv-openocd. When I didn't add '-rtos linux' in openocd.cfg to debug the Linux kernel, I got the error message I mentioned above.
Halt the Linux kernel
Add the breakpoint
The wrong messages
As I said above add the '-rtos linux' would work fine.
Ok, so what exactly is the problem?
The memory read errors may be correct if there is no actual memory implemented at the target addresses. E.g. 0xffffffff80c0b3ae looks like a strange address. The debugger could be trying to access it due to garbage register or memory contents when it connects to and halts the target - e.g. when trying to walk the call stack but starting at a garbage address.
This doesn't necessarily indicate any problem with OpenOCD.
If you built the latest OpenOCD then this issue:
- https://github.com/riscv/riscv-openocd/issues/559
mentioned here:
- https://forums.sifive.com/t/openocd-failed-to-read-memory/5791
is irrelevant.
This is the objdump result of the breakpoint smp_init
This is the objdump result of the breakpoint start_kernel
As Tommy points out, -rtos is if you want gdb on one system to see the individual threads on the target system. If you're debugging the kernel this is almost certainly not what you want.
The only RTOS I've used with RISC-V is FreeRTOS, and it took a significant amount of work to to make OpenOCD support it. I would be surprised if everything works with Linux without any modifications to OpenOCD. That said, I know people have used OpenOCD without -rtos to work on the Linux kernel.
There is someone who used OpenOCD to debug the Linux kernel on the SiFive Unmatched board. https://forums.sifive.com/t/debug-linux-kernel-with-openocd-gdb/5717 He finally gave up on a pure GDB solution and went with FreedomStudio. As he described using the pure GDB solution, Linux kernel debugging has still some problems. My work is on FreeBSD, so I don't really care about debugging on Linux. I use the same way above mentioned to debug FreeBSD without '-rtos' (FreeBSD has not the option), add breakpoints, FreeBSD no output logs, but Linux gives the wrong message, on FreeBSD the breakpoints never hit. Is the same operating system associated with different architectures? That is to say, ARM and RISCV have the different behavior when use '-rtos' or not. Some people have used OpenOCD without '-rtos' to work on the Linux kernel, he or she uses the ARM instead of RISCV?
Is the same operating system associated with different architectures? That is to say, ARM and RISCV have the different behavior when use '-rtos' or not. Some people have used OpenOCD without '-rtos' to work on the Linux kernel, he or she uses the ARM instead of RISCV?
I'm pretty sure that @timsifive is referring to people debugging the kernel running on RISC-V successfully without -rtos linux. As both he and I said, that is not required for debugging the kernel.
I don't really understand why you seem to be getting different results with and without -rtos linux, and, it seems, better results with it. But it may be worth comparing a verbose OpenOCD log (using -d3) for each case to see what differences there are.