Closed xobs closed 5 years ago
It works the other way. If the lower 2 bits are set, then it is a 32-bit instruction, and ebreak is used. It isn't clear why this code isn't working for you. I would suggest adding some printfs to this code to see why it isn't working for you.
Depending on what version of GDB you are using you might be running into this bug: https://sourceware.org/ml/gdb-patches/2019-07/msg00450.html This was fixed in upstream GDB but will not be in any release yet. You should try rebuilding with current upstream HEAD and see if that resolves the issue for you.
I can verify that the latest version fixes it. Previously I was using a precompiled version from https://www.sifive.com/boards/ which still exhibits the issue.
Since this is fixed upstream, I'll close the issue.
Similar to #106, gdb is using compressed instructions on my platform that doesn't support them. This results in surprising behavior and traps, and took a while to track down.
It looks like what it does is investigate the target opcode, and if the lower two bits are set it assumes the target supports
C.EBREAK
: https://github.com/riscv/riscv-binutils-gdb/blob/riscv-binutils-2.32/gdb/riscv-tdep.c#L439 (which then calls https://github.com/riscv/riscv-binutils-gdb/blob/82dcb8613e1b1fb2989deffde1d3c9729695ff9c/include/opcode/riscv.h#L30)In my debugger I'm trying to do a
call
to a function that starts out with alui
instruction:0x10001537 ; lui a0,0x10001
. This opcode is not a compressed instruction, yet the bottom two bits are set.What ends up happening is gdb decides the target supports 16-bit opcodes, and then things go south.
It's possible to do
set riscv use-compressed-breakpoints off
, which does fix the issue. However, it would be nice if the default didn't result in mysterious hangs and debugger crashes.