Aaron Lindsay <[email protected]> writes:
> On Dec 08 17:56, Alex Bennée wrote: >> Aaron Lindsay <[email protected]> writes: >> > On Dec 08 12:17, Alex Bennée wrote: >> >> For registers I think there needs to be some re-factoring of QEMU's >> >> internals to do it cleanly. Currently we have each front-end providing >> >> hooks to the gdbstub as well as building up their own regid and xml to >> >> be consumed by it. We probably want a architectural neutral central >> >> repository that the front ends can register their registers (sic) and >> >> helpers with. This would then provide hooks for gdbstub to cleanly >> >> generate XML as well as an interface point for the plugin infrastructure >> >> (and probably whatever the HMP uses as well). >> > >> > In a previous incarnation, I was proxying calls to the plugin API >> > directly through to gdb_read_register() in gdbstub.c and therefore using >> > gdb as the point of commonality. I'm not saying it's ideal but... it >> > works? One downside is that you have to know 'out-of-band' which integer >> > value corresponds to the register you want to query for your >> > architecture, though it hasn't been a significant issue for me. >> >> Certainly workable for a private branch but I don't want to merge >> anything like that upstream. > > Sure - I was more commenting on what I've done in case it's useful than > pushing for it to be upstreamed! > >> As far as I can see there are a number of >> consumers of register information: >> >> - plugins >> - gdbstub >> - monitor (info registers) >> - -d LOG_CPU logging >> >> so rather than have them all have their hooks into every front-end I can >> see a case for consolidation. >> >> For the plugin case providing an introspection helper to get a handle on >> the register makes sense and would be less painful than teachning >> plugins about gdb regids which can and do move around with new system >> registers. >> >> qemu_plugin_reg_t *handle = qemu_plugin_find_register("x2") >> >> if we document the handle as usable across calls this can be done on >> start-up. Then it would be: >> >> uint64_t val = qemu_plugin_read_register(cpu_index, handle); > > I recognize this is pseudocode, but I'm wondering "out loud" if this > would need to be variable-width instead of a uint64_t to allow for wider > registers in an actual implementation. Yeah probably. The current internal interface for gdb uses GByteArray's so that may be something you pass into the read function. > > -Aaron -- Alex Bennée
