Re: [PATCH v2 1/5] RISC-V: larger and more consistent register set for 'info registers'

[Alex Bennée]

"Schwarz, Konrad" <konrad.schwarz@siemens.com> writes:

>> -----Original Message-----
>> From: Richard Henderson <richard.henderson@linaro.org>
>> Sent: Tuesday, January 4, 2022 21:57
>> Subject: Re: [PATCH v2 1/5] RISC-V: larger and more consistent register set 
>> for 'info registers'
>> 
>> On 1/4/22 7:51 AM, Konrad Schwarz wrote:
>> >           static const int dump_csrs[] = {
>> > +
>> > +#  if 0
>> > +            CSR_USTATUS,
>> > +            CSR_UIE,
>> > +            CSR_UTVEC,
>> 
>> Adding huge sections of #if 0 code is not acceptable.
>
> I'm not sure on how to solve the dilemma of
>
> * transgressing on QEMUs coding guidelines on the one side
>   (large sections of commented out code)
>
> * having `info registers' output a huge swath of CSRs,
>   swamping the user and making the command impractical
>
> I feel that providing some control at compile
> time via `# if' conditional compilation is preferrable to just dumping
> everything.  I could of course only list the CSRs that
> are interesting to me, currently, but I thought it
> would be better to list (almost) all of them and give at least
> programmers an easy way to enable the blocks of CSRs
> that are of interest to them.
>
> Obviously, the best solution would be to extend the command to
> add a filter argument, similar to GDB's `info registers'
> (i.e. info registers XXX), but I don't know how to do that in QEMU and
> it would work differently from other target architectures.

This is a problem that needs solving not only for "info registers" but
also things like "-d cpu", gdbserver and (eventually) TCG plugins.

My (so far unrealised) vision is to have a architecture independent
sub-system that we can register (sic) registers. The frontends would
replace their existing qemu_log and gdbserver hooks with a group aware
registering function to the sub-system. For example:

  register_reg("x0", REG_CORE, get_gen_reg, set_gen_reg, offsetof(CPUARMState, 
xregs[0]))
  register_reg(ri->name, REG_SYSTEM, get_cpreg, set_cpreg, ri);

and so on. This would then provide a common point for the register value
consumers to request values and sets. So we could have options like:

  (hmp) info registers fpu
  -d cpu:pc
  qemu_plugin_get_regset("x0-x7");

and avoid having too much per-architecture special casing. I'd also like
to get rid of custom gdb XML generation in the frontends (e.g.
arm_gen_dynamic_svereg_xml) and make that common functionality.

> What would you suggest?

-- 
Alex Bennée