Details
- Reviewers
jhb - Group Reviewers
riscv - Commits
- rGd25147c01a20: riscv: gdb(4) support
rGd72e944812f8: riscv: gdb(4) support
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 43689 Build 40577: arc lint + arc unit
Event Timeline
| sys/riscv/riscv/gdb_machdep.c | ||
|---|---|---|
| 55–63 | arm64 will only read lr, sp, pc (as elr) and cpsr (as spsr) from the trapframe, with all other X registers falling back on kdb_thrctx, whereas amd64 splits it based on saved vs not saved. Is that just because arm64 is stupid and redundantly saves all the call-clobbered registers in its pcb? | |
| 87 | arm64 and amd64 have (different) comments about deliberately writing to both the trapframe and the pcb for the current thread | |
| sys/riscv/include/gdb_machdep.h | ||
|---|---|---|
| 33 | Does this need to be 36 to cover sstatus+stval+scause? | |
| sys/riscv/include/gdb_machdep.h | ||
|---|---|---|
| 33 | Yes, it does. Not sure how I landed on this value but I believe those should also be included in the 'g' register payload. | |
| sys/riscv/riscv/gdb_machdep.c | ||
| 55–63 | I think yes, because the arm64 pcb tracks every X register it could be expressed very simply for that version. | |
According to https://github.com/bminor/binutils-gdb/blob/master/gdb/features/riscv/64bit-fpu.xml, register number 33 is ft0, with https://github.com/bminor/binutils-gdb/blob/master/gdb/features/riscv/64bit-cpu.xml stopping at PC. https://github.com/bminor/binutils-gdb/blob/master/gdb/riscv-tdep.h#L48 is consistent with that and has CSRs start at 65, so sstatus/stval/scause would be 0x141/0x184/0x183 by my calculations. I can see Linux is using the constants you use here, but I assume that only works because they send back their own target description XML.
So, I think GDB_NREGS should be put back at 33, and the CSRs updated to have the appropriate numbers. That way g/G will just access the GPRs+PC and p/P will be able to access the CSRs.
Done. I was hoping to test the CSR read/write, but it seems the default remote target only includes the GPRs. Perhaps in the future we can have the gdb stub send its own target xml description.