[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 06/23] tests/tcg: add an explicit gdbstub register tester
|
From: |
Luis Machado |
|
Subject: |
Re: [PULL 06/23] tests/tcg: add an explicit gdbstub register tester |
|
Date: |
Thu, 16 Nov 2023 09:56:40 +0000 |
|
User-agent: |
Mozilla Thunderbird |
On 11/15/23 20:56, Alex Bennée via Gdb wrote:
> "Nicholas Piggin" <npiggin@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.machado@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.
- [PULL 03/23] target/arm: mark the 32bit alias of PAR when LPAE enabled, (continued)
- [PULL 03/23] target/arm: mark the 32bit alias of PAR when LPAE enabled, Alex Bennée, 2023/11/07
- [PULL 02/23] gdb-xml: fix duplicate register in arm-neon.xml, Alex Bennée, 2023/11/07
- [PULL 01/23] default-configs: Add TARGET_XML_FILES definition, Alex Bennée, 2023/11/07
- [PULL 05/23] target/arm: hide aliased MIDR from gdbstub, Alex Bennée, 2023/11/07
- [PULL 10/23] gdbstub: Introduce GDBFeatureBuilder, Alex Bennée, 2023/11/07
- [PULL 08/23] gdbstub: Add num_regs member to GDBFeature, Alex Bennée, 2023/11/07
- [PULL 12/23] configure: tell meson and contrib_plugins about DLLTOOL, Alex Bennée, 2023/11/07
- [PULL 06/23] tests/tcg: add an explicit gdbstub register tester, Alex Bennée, 2023/11/07
[PULL 14/23] plugins: make test/example plugins work on windows, Alex Bennée, 2023/11/07
[PULL 13/23] plugins: add dllexport and dllimport to api funcs, Alex Bennée, 2023/11/07
[PULL 15/23] plugins: disable lockstep plugin on windows, Alex Bennée, 2023/11/07
[PULL 11/23] cpu: Call plugin hooks only when ready, Alex Bennée, 2023/11/07
[PULL 16/23] gitlab: add dlltool to Windows CI, Alex Bennée, 2023/11/07
[PULL 22/23] mailmap: fixup some more corrupted author fields, Alex Bennée, 2023/11/07
[PULL 17/23] plugins: allow plugins to be enabled on windows, Alex Bennée, 2023/11/07
[PULL 07/23] tests/avocado: update the tcg_plugins test, Alex Bennée, 2023/11/07
[PULL 09/23] gdbstub: Introduce gdb_find_static_feature(), Alex Bennée, 2023/11/07