Summary: | sim: align sim register numbers with gdb register numbers | ||
---|---|---|---|
Product: | gdb | Reporter: | Mike Frysinger <vapier> |
Component: | sim | Assignee: | Mike Frysinger <vapier> |
Status: | NEW --- | ||
Severity: | normal | CC: | tromey, vapier |
Priority: | P2 | ||
Version: | unknown | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Mike Frysinger
2022-12-10 12:23:57 UTC
I randomly hack on this and while looking at it today I realized I don't know how to find the number of registers for a particular sim. Is this available? gdbserver wants to iterate over all the registers in its 'fetch_registers' (and also store) callback. include/sim/sim-<arch>.h Hmm, that's missing for some arches. Then I thought about just reusing the xml register descriptions, but those are also missing in some cases. on the sim side, the key is to start with CPU_REG_FETCH & CPU_REG_STORE. those set the callbacks for gdb to read/write registers via register number. ports with sim headers: aarch64 arm bfin cr16 d10v frv ft32 h8300 lm32 m32c ppc riscv rl78 rx sh ports w/out gdb support so don't super care: example-synacor mcore pru ports that copy & paste register numbers between gdb & sim so they're the same: avr (AVR_xxx_REGNUM) bpf (BPF_Rxx) iq2000 (xxx_REGNUM) m32r (xxx_REGNUM) -- although it seems they aren't completely in sync m68hc11 (xxx_REGNUM) microblaze (NUM_REGS) mn10300 (struct _state.regs & xxx_REGNUM) moxie (struct moxie_regset.regs & xxx_REGNUM) msp430 (struct msp430_cpu_state.regs & MSP430_xxx_REGNUM) v850 (struct _v850_regs.regs & .sregs & E_xxx_REGNUM) ports w/gdb port & w/out sim headers that i'm not sure if/how they work: cris erc32(sparc) mips(many ISAs) or1k ppc The issue for gdbserver integration is that a general request may arrive, which just means "send all the registers". So, the server has to know how to iterate over them. Digging a bit I see this info in some ports, but it's not generically available via the sim public API. It works in gdb due to the synchronicity you point out: gdb and the sim generally agree (or there is a mapping). I don't really understand why this info isn't in the cgen model either, but it doesn't seem to be. Anyway I suspect a new field in _sim_cpu may be the way to go... Though looking at this, we also don't know the size of registers. gdb does, but it doesn't inform the remote of this -- the remote is expected to know. (In reply to Tom Tromey from comment #5) > I don't really understand why this info isn't in the cgen model > either, but it doesn't seem to be. i don't think it makes sense for cgen to know about this. what we're talking about here is a communication protocol for serializing & deserializing state, and GDB defines that protocol. > Anyway I suspect a new field in _sim_cpu may be the way to go... while converting the sim to RSP completely is a pretty heavy lift, i think we have some incremental steps we could consider * have gdb maintain the lists, and automatically convert/generate/export them to sim in the source tree. if there are XML files, use those. if there are enums in header files, use those. we already do this sort of thing with newlib via sim/common/gennltvals.py, and we commit the result (rather than gen at build time via portable shell/etc...). i think we have/want to do this regardless. * add a parallel set of sim_{store,fetch}_register APIs that used the same encoding as RSP. > Though looking at this, we also don't know the size of registers. > gdb does, but it doesn't inform the remote of this -- the remote > is expected to know. when it comes to the sim APIs, gdb calls the sim with the size. sim_fetch_register & sim_store_register both have a "length", and the sim basically treats it as "it has to match the register size requested via regno". sim_fetch_register also is designed such that passing in length=0 will return the size of the requested register without writing to the buffer. so callers could cheaply probe the size of all registers. Ok, I have a proof of concept on my github. https://github.com/tromey/gdb/tree/t/random-sim-hacking-2 This builds a gdbserver for moxie. The main content is in sim/common/sim-target.cc ... with various build hacks and whatnot to support this. I have not tested it at all. |