gdb access to CSRs

[Tim Newsome]

The current RISCV gdb support only allows access to a limited amount of CSRs. Since people will presumably use CSRs for custom features, there needs to be a way to access every CSR regardless of whether gdb actually knows what it's used for.

I can think of two possible implementations:

1. Add a named register for each CSR (eg. csr0, csr1, ..., csr4095). I'm not sure how nicely this plays with gdb's implementation. It may be necessary to grow the register cache to hold every one of those registers. (Admittedly on modern hosts 32KB isn't much RAM.)

2. Add a separate command to access CSRs, eg. "csrr 5" to read CSR 5, and "csrw 5 0xdead" to write 0xdead to CSR 5.

Does anybody have any opinions on this matter?

Tim

[Mike Frysinger]

gdb has an xml spec for defining registers.  we'll want to convert the gdb port to use that instead of hardcoding the CSR list at compile time.  then people can supply their own xml file with their own names to gdb.

-mike

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAGDihemdMv1EbaTivufhtcq8JPkX2PVraQqx3vE9_Wh0E9_P%2Bw%40mail.gmail.com.

[Tim Newsome]

On Mon, Mar 14, 2016 at 10:24 PM, Mike Frysinger <vap...@gmail.com> wrote:

gdb has an xml spec for defining registers.  we'll want to convert the gdb port to use that instead of hardcoding the CSR list at compile time.  then people can supply their own xml file with their own names to gdb.

That sounds like a good idea, but there ought to be a way to access CSRs by number. When I'm working on something new, and I want to access CSR 8672 I just want to type the number and see it. Writing an XML file is going to be a major annoyance at that point.

Tim

[Andrew Waterman]

I'd favor baked-in numerical access to all CSRs, with names provided
by the XML file.

> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAGDihe%3Deci2gtwTJfh5HbzOVaK6Vokgv1bzXbRgyd8ZRcbP0nQ%40mail.gmail.com.

[Mike Frysinger]

that should be doable.  i don't think the gdb C code can easily generate pseudo regs for CSRs on the fly, so dumping them all in the XML would be saner.

-mike

[Tim Newsome]

On Tue, Mar 15, 2016 at 11:59 AM, Mike Frysinger <vap...@gmail.com> wrote:

that should be doable.  i don't think the gdb C code can easily generate pseudo regs for CSRs on the fly, so dumping them all in the XML would be saner.

I'm going with the dumb implementation of just explicitly enumerating all 4096 CSR registers. It seems to work alright. (I'll make sure they don't all show up in 'show reg all'.) That does lead to another question:

How many existing dependencies are there on the register numbering scheme? Eg. currently fflags has register number 65. After my change it has number 66 (to make room for csr0). I could keep the existing numbers as-is, but it'd make both server and client code a lot more complex.

Tim

[Mike Frysinger]

i'd have to double check, but the only place where the reg # might be exposed is via the machine interface (gdb/mi).  that'll come up with remote stubs such as gdbserver.

the sim has its own abi of register #'s that are stable/independent of gdb.

-mike