search

riscv-collab / riscv-openocd

Fork of OpenOCD that has RISC-V support
Other
450 stars 327 forks source link

GD32VF103 behaves strangely when stepping after a breakpoint #557

Closed protobits closed 3 years ago

protobits commented 3 years ago

I'm getting strange results when stepping through code with GD32VF103. I have a code that reads a register (RCU_CFG0) and the next line has an if over that value. If I place the breakpoint on the assignment and step once, the value of the register is not zero as it should be from reset. However, I can see that reading the register via gdb retrieves a zero value at that point. If I place a second breakpoint on the if and continue right after the first breakpoint is reached, the variable now holds a zero value. So it would appear that single-stepping from a breakpoint somehow affects reading from memory.

Maybe this was what this user was referring to: https://github.com/riscv/riscv-openocd/pull/518#issuecomment-691710695 Are there any known issues with this chip or any errata? (there's at least already one regarding reset apparently)

protobits commented 3 years ago

If it helps, I find that step by instruction I see that at this point a5 contains 0x40021000 as expected:

image

But stepping one instruction again makes a5 go to zero, instead of 0x40021004. So I'm not sure what is happening.

timsifive commented 3 years ago

It's not obvious to me exactly what you did. The arrow in your screenshot points to a point in the code before regval actually gets the new value.

Are you using step/stepi?

Best is probably to include the gdb session with the commands you ran that gave the confusing result.

protobits commented 3 years ago

Hi, sorry, this was long time ago and cannot reproduce it right now. But from my testing at the time I found that it happened with one gdb but not other from different toolchain. I think that the latest version from SiFive was working but not other ones. As I needed a python-capable gdb and the latest one had an issue (reported here https://github.com/sifive/freedom-tools/issues/71) I couldn't continue testing.

protobits commented 3 years ago

It's not obvious to me exactly what you did. The arrow in your screenshot points to a point in the code before regval actually gets the new value.

Are you using step/stepi?

Best is probably to include the gdb session with the commands you ran that gave the confusing result.

Yes, as I mentioned, at that point the register was OK, but one instruction later (executing the addi) made the register value incorrect.

TommyMurphyTM1234 commented 3 years ago

Could this issue be relevant here I wonder?

https://github.com/riscv/riscv-openocd/issues/559

As mentioned in that issue there are many places where openocd could potentially corrupt registers.

timsifive commented 3 years ago

That sounds possible. Given that the problem no longer reproduces, I'm inclined to close this issue. Thoughts?

protobits commented 3 years ago

Sure, thanks