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.