Re: [PATCH v2 4/5] RISC-V: Typed CSRs in gdbserver

["Alex Bennée" <alex.bennee@linaro.org>]

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

>> -----Original Message-----
>> From: Alex Bennée <alex.bennee@linaro.org>
>
>> Konrad Schwarz <konrad.schwarz@siemens.com> writes:
>> 
>
>> >  static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
>> >  {
>> >      RISCVCPU *cpu = RISCV_CPU(cs);
>> > @@ -163,21 +167,33 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
>> >      riscv_csr_predicate_fn predicate;
>> >      int bitsize = 16 << env->misa_mxl_max;
>> >      int i;
>> > +    riscv_csr_operations *csr_op;
>> > +    struct riscv_gdb_csr_tg const *csr_tg;
>> >
>> >      g_string_printf(s, "<?xml version=\"1.0\"?>");
>> >      g_string_append_printf(s, "<!DOCTYPE feature SYSTEM \"gdb-target.dtd\">");
>> >      g_string_append_printf(s, "<feature>      name=\"org.gnu.gdb.riscv.csr\">");
>> 
>> With these changes does it still match the org.gnu.gdb.riscv.csr
>> register description in gdb? Previously for custom XML I've used the
>> org.qemu.ARCH.REGS form to distinguish between something GDB expects and
>> something we invented (changed since 797920b952ea).
>
> I don't expect it to match -- but why should it?
> The whole point of target descriptions is for GDBserver to inform
> GDB of the precise set and layout of pre-defined register classes.
> The class `org.gnu.gdb.riscv.csr' is known to a RISC-V capable
> GDB as the class of all CSRs; a specific RISC-V core might
> have vendor-specific CSRs, but they would still be included
> in `org.gnu.gdb.riscv.csr'.

Certainly for ARM's SVE there is special handling code in gdb to deal
with the control of the vector length. As long as GDB doesn't make any
such assumptions for RISC-V then go right ahead.

>
> Section G.5 in the GDB manual makes this clear:
> "You can add additional registers to any of the standard features --
> GDB will display them just as they were added to an
> unrecognized feature."


-- 
Alex Bennée