Re: [PULL 06/23] tests/tcg: add an explicit gdbstub register tester

Luis Machado <[email protected]> Thu, 16 Nov 2023 09:56:40 +0000
Newsgroups gmane.comp.emulators.qemu,gmane.comp.gdb.general
Message-ID <[email protected]>
On 11/15/23 20:56, Alex Benn=C3=A9e via Gdb wrote:
> "Nicholas Piggin" <[email protected]> writes:
>
>> On Wed Nov 8, 2023 at 12:23 AM AEST, Alex Benn=C3=A9e wrote:
>>> We already do a couple of "info registers" for specific tests but this
>>> is a more comprehensive multiarch test. It also has some output
>>> helpful for debugging the gdbstub by showing which XML features are
>>> advertised and what the underlying register numbers are.
>>>
>>> My initial motivation was to see if there are any duplicate register
>>> names exposed via the gdbstub while I was reviewing the proposed
>>> register interface for TCG plugins.
>>>
>>> Mismatches between the xml and remote-desc are reported for debugging
>>> but do not fail the test.
>>>
>>> We also skip the tests for the following arches for now until we can
>>> investigate and fix any issues:
>>>
>>>   - s390x (fails to read v0l->v15l, not seen in remote-registers)
>>>   - ppc64 (fails to read vs0h->vs31h, not seen in remote-registers)
>>
>> binutils-gdb.git/gdb/rs6000-tdep.c has:
>>
>> static const char *
>> rs6000_register_name (struct gdbarch *gdbarch, int regno)
>> {
>>   ppc_gdbarch_tdep *tdep =3D (ppc_gdbarch_tdep *) gdbarch_tdep (gdbarch)=
;
>>
>>   /* The upper half "registers" have names in the XML description,
>>      but we present only the low GPRs and the full 64-bit registers
>>      to the user.  */
>>   if (tdep->ppc_ev0_upper_regnum >=3D 0
>>       && tdep->ppc_ev0_upper_regnum <=3D regno
>>       && regno < tdep->ppc_ev0_upper_regnum + ppc_num_gprs)
>>     return "";
>>
>>   /* Hide the upper halves of the vs0~vs31 registers.  */
>>   if (tdep->ppc_vsr0_regnum >=3D 0
>>       && tdep->ppc_vsr0_upper_regnum <=3D regno
>>       && regno < tdep->ppc_vsr0_upper_regnum + ppc_num_gprs)
>>     return "";
>>
>> (s390 looks similar for V0-V15 lower).
>>
>> I guess it is because the upper half is not a real register but an
>> extension of an existing FP register to make a vector register. I
>> just don't know how that should be resolved with QEMU.
>>
>> Should we put an exception in the test case for these? Or is there
>> something we should be doing differently with the XML regs?
>
> Yeah I suspect this is just inconsistency between targets on gdb. My
> naive assumption was XML should match the displayed registers but it
> seems there is additional filtering going on.
>
> It seems in this case the registers are still there and have regnums (so
> I assume the stub could be asked for them) but the names have been
> squashed. I guess we could detect that and accept it?
>
>>
>> i386 gdb does similar:
>>
>> static const char *
>> i386_register_name (struct gdbarch *gdbarch, int regnum)
>> {
>>   /* Hide the upper YMM registers.  */
>>   if (i386_ymmh_regnum_p (gdbarch, regnum))
>>     return "";
>>
>>   /* Hide the upper YMM16-31 registers.  */
>>   if (i386_ymmh_avx512_regnum_p (gdbarch, regnum))
>>     return "";
>>
>>   /* Hide the upper ZMM registers.  */
>>   if (i386_zmmh_regnum_p (gdbarch, regnum))
>>     return "";
>>
>>   return tdesc_register_name (gdbarch, regnum);
>> }
>>
>> So, I'm not sure how they don't fail this test. Does QEMU just
>> not have YMM/ZMM in XML regmap?
>
> No I think we only send the core one with XMM regs and there are no
> additional registers sent via gdb_register_coprocessor.
>
>>
>> Thanks,
>> Nick

FTR, [email protected] doesn't exist anymore.

As for the XML, it serves as an architecture hint/description of what featu=
res and registers
are available.

GDB will process that and will potentially include additional pseudo-regist=
ers (so QEMU doesn't
need to do so, unless it is some pseudo-register not accounted by gdb).

The rest of the features/registers gdb doesn't care about, it will just add=
 them to the end of the
list, and will assign whatever number is next. GDB will be able to read/wri=
te them, but nothing more
than that.
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.