On 11/15/23 20:56, Alex Bennée via Gdb wrote:
> "Nicholas Piggin" <npig...@gmail.com> writes:
>
>> On Wed Nov 8, 2023 at 12:23 AM AEST, Alex Bennée 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 = (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 >= 0
>> && tdep->ppc_ev0_upper_regnum <= 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 >= 0
>> && tdep->ppc_vsr0_upper_regnum <= 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, luis.mach...@linaro.org doesn't exist anymore.
As for the XML, it serves as an architecture hint/description of what features
and registers
are available.
GDB will process that and will potentially include additional pseudo-registers
(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/write
them, but nothing more
than that.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please 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.
