Page MenuHomeFreeBSD

riscv: gdb(4) support
ClosedPublic

Authored by mhorne on Jan 3 2022, 10:55 PM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 8 2024, 3:28 AM
Unknown Object (File)
Jan 29 2024, 1:17 PM
Unknown Object (File)
Jan 12 2024, 7:44 AM
Unknown Object (File)
Dec 27 2023, 1:20 AM
Unknown Object (File)
Dec 23 2023, 12:00 AM
Unknown Object (File)
Nov 11 2023, 11:35 PM
Unknown Object (File)
Nov 8 2023, 2:30 AM
Unknown Object (File)
Nov 5 2023, 7:57 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Jan 3 2022, 11:39 PM
jrtc27 added inline comments.
sys/riscv/riscv/gdb_machdep.c
56–64

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?

88

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
34

Does this need to be 36 to cover sstatus+stval+scause?

sys/riscv/include/gdb_machdep.h
34

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
56–64

I think yes, because the arm64 pcb tracks every X register it could be expressed very simply for that version.

This revision now requires review to proceed.Jan 4 2022, 2:13 PM

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.

Fix CSR register numbers, reduce GDB_NREGS back down to 33 for now.

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.

This revision was not accepted when it landed; it landed in state Needs Review.Jan 10 2022, 5:41 PM
Closed by commit rGd72e944812f8: riscv: gdb(4) support (authored by mhorne). · Explain Why
This revision was automatically updated to reflect the committed changes.