Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado via Gdb <gdb@sourceware.org>
To: "Alex Bennée" <alex.bennee@linaro.org>,
	"Nicholas Piggin" <npiggin@gmail.com>
Cc: qemu-devel@nongnu.org, "Akihiko Odaki" <akihiko.odaki@daynix.com>,
	"Luis Machado" <luis.machado@linaro.org>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	qemu-s390x@nongnu.org,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	qemu-ppc@nongnu.org, "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"David Hildenbrand" <david@redhat.com>,
	"gdb@gnu.org" <gdb@gnu.org>
Subject: Re: [PULL 06/23] tests/tcg: add an explicit gdbstub register tester
Date: Thu, 16 Nov 2023 09:56:40 +0000	[thread overview]
Message-ID: <37df0557-faf0-4667-925f-fcc7deac4f52@arm.com> (raw)
In-Reply-To: <87il62vip5.fsf@draig.linaro.org>

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.

  reply	other threads:[~2023-11-16 10:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20231107142354.3151266-1-alex.bennee@linaro.org>
     [not found] ` <20231107142354.3151266-7-alex.bennee@linaro.org>
     [not found]   ` <CWXN9HF4AXGM.19H4A5BU366S1@wheely>
2023-11-15 20:56     ` Alex Bennée via Gdb
2023-11-16  9:56       ` Luis Machado via Gdb [this message]
2023-11-16 14:59         ` Alex Bennée via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37df0557-faf0-4667-925f-fcc7deac4f52@arm.com \
    --to=gdb@sourceware.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=alex.bennee@linaro.org \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=david@redhat.com \
    --cc=gdb@gnu.org \
    --cc=iii@linux.ibm.com \
    --cc=luis.machado@arm.com \
    --cc=luis.machado@linaro.org \
    --cc=npiggin@gmail.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox