public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Simon Marchi <simark@simark.ca>, John Baldwin <jhb@FreeBSD.org>,
	gdb-patches@sourceware.org
Cc: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Subject: Re: [PATCH v4 01/13] x86: Add an x86_xsave_layout structure to handle variable XSAVE layouts.
Date: Tue, 11 Apr 2023 15:23:20 +0100	[thread overview]
Message-ID: <4da73147-3fe8-ecf8-8133-5df102243b74@palves.net> (raw)
In-Reply-To: <f98b4249-fef2-35b8-0f84-2dad6cf8bad1@simark.ca>

On 2023-04-06 8:09 p.m., Simon Marchi via Gdb-patches wrote:

> 
>> +i386_fetch_xsave_layout ()
>> +{
>> +  struct x86_xsave_layout layout;
>> +  LONGEST len = target_read (current_inferior ()->top_target (),
>> +			     TARGET_OBJECT_X86_XSAVE_LAYOUT, nullptr,
>> +			     (gdb_byte *) &layout, 0, sizeof (layout));
>> +  if (len != sizeof (layout))
>> +    return {};
> 
> Do you have an idea of which conditions can make it so `len != sizeof
> (layout)`?  If I understand correctly, the contract for
> TARGET_OBJECT_X86_XSAVE_LAYOUT is that the caller passes a pointer to an
> x86_xsave_layout object and the callee fills it.  This is all internal
> to GDB.  I don't imagine how a target could return something else than
> ;`sizeof (layout)` (indicating success) or TARGET_XFER_E_IO (indicating
> failure), other than being buggy.
> 
> All of this to say, should it be an assert?

How is this meant to work with remote debugging, though?  Is
a TARGET_OBJECT_X86_XSAVE_LAYOUT object going to be crossing over the
remote protocol?  If so, it's fine if the object is binary, but, we need to consider
the case of the host running GDB not being x86, and not even being little endian.
I.e., we can't just cast byte buffer to x86_xsave_layout and expect that it works.

> 
>> +/* Size and offsets of register states in the XSAVE area extended
>> +   region.  Offsets are set to 0 to indicate the absence of the
>> +   associated registers.  */
>> +
>> +struct x86_xsave_layout
>> +{
>> +  int sizeof_xsave = 0;
>> +  int avx_offset = 0;
>> +  int bndregs_offset = 0;
>> +  int bndcfg_offset = 0;
>> +  int k_offset = 0;
>> +  int zmm_h_offset = 0;
>> +  int zmm_offset = 0;
>> +  int pkru_offset = 0;
>> +
>> +  bool operator!= (const x86_xsave_layout &other)
>> +  {
>> +    return sizeof_xsave != other.sizeof_xsave
>> +      || avx_offset != other.avx_offset
>> +      || bndregs_offset != other.bndregs_offset
>> +      || bndcfg_offset != other.bndcfg_offset
>> +      || k_offset != other.k_offset
>> +      || zmm_h_offset != other.zmm_h_offset
>> +      || zmm_offset != other.zmm_offset
>> +      || pkru_offset != other.pkru_offset;
>> +  }
> 
> Heh, would be nice to be able to use
> 
> https://en.cppreference.com/w/cpp/language/default_comparisons
> 
> !
> 

In this particular case, we could write the op instead as:

  bool operator!= (const x86_xsave_layout &other)
  {
    /* Just to make sure memcpy isn't comparing padding.  */
    static_assert (sizeof (x86_xsave_layout) == 8 * sizeof (int));

    return memcmp (this, &other, sizeof (x86_xsave_layout)) != 0;
  }

  parent reply	other threads:[~2023-04-11 14:23 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-18  1:08 [PATCH v4 00/13] Handle " John Baldwin
2023-03-18  1:08 ` [PATCH v4 01/13] x86: Add an x86_xsave_layout structure to handle " John Baldwin
2023-03-28 11:35   ` George, Jini Susan
2023-04-10 19:28     ` John Baldwin
2023-04-06 19:09   ` Simon Marchi
2023-04-10 20:03     ` John Baldwin
2023-04-11  1:19       ` Simon Marchi
2023-04-11 14:23     ` Pedro Alves [this message]
2023-04-11 16:02       ` John Baldwin
2023-03-18  1:08 ` [PATCH v4 02/13] core: Support fetching TARGET_OBJECT_X86_XSAVE_LAYOUT from architectures John Baldwin
2023-04-06 19:28   ` Simon Marchi
2023-04-10 20:42     ` John Baldwin
2023-04-11  1:49       ` Simon Marchi
2023-04-11 16:06         ` John Baldwin
2023-04-11 16:21           ` Simon Marchi
2023-04-11 23:59             ` John Baldwin
2023-03-18  1:08 ` [PATCH v4 03/13] nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count John Baldwin
2023-04-06 19:33   ` Simon Marchi
2023-04-10 20:49     ` John Baldwin
2023-04-11  1:49       ` Simon Marchi
2023-03-18  1:08 ` [PATCH v4 04/13] x86 nat: Add helper functions to save the XSAVE layout for the host John Baldwin
2023-04-06 19:40   ` Simon Marchi
2023-04-10 21:00     ` John Baldwin
2023-04-11  1:51       ` Simon Marchi
2023-03-18  1:08 ` [PATCH v4 05/13] gdb: Update x86 FreeBSD architectures to support XSAVE layouts John Baldwin
2023-04-06 19:54   ` Simon Marchi
2023-04-10 21:02     ` John Baldwin
2023-04-11  1:55       ` Simon Marchi
2023-03-18  1:08 ` [PATCH v4 06/13] gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets John Baldwin
2023-04-06 20:18   ` Simon Marchi
2023-04-10 21:27     ` John Baldwin
2023-04-11  2:23       ` Simon Marchi
2023-04-11 16:19         ` John Baldwin
2023-04-11 16:46           ` Simon Marchi
2023-04-11 21:37             ` John Baldwin
2023-04-11 22:35               ` John Baldwin
2023-04-12 14:35                 ` Simon Marchi
2023-03-18  1:08 ` [PATCH v4 07/13] gdb: Update x86 Linux architectures to support XSAVE layouts John Baldwin
2023-04-07  1:43   ` Simon Marchi
2023-04-10 21:29     ` John Baldwin
2023-03-18  1:09 ` [PATCH v4 08/13] gdb: Support XSAVE layouts for the current host in the Linux x86 targets John Baldwin
2023-04-07  1:54   ` Simon Marchi
2023-03-18  1:09 ` [PATCH v4 09/13] gdb: Use x86_xstate_layout to parse the XSAVE extended state area John Baldwin
2023-04-07  2:13   ` Simon Marchi
2023-04-10 21:40     ` John Baldwin
2023-03-18  1:09 ` [PATCH v4 10/13] gdbserver: Add a function to set the XSAVE mask and size John Baldwin
2023-04-12 15:08   ` Simon Marchi
2023-04-27 17:24     ` John Baldwin
2023-03-18  1:09 ` [PATCH v4 11/13] gdbserver: Refactor the legacy region within the xsave struct John Baldwin
2023-04-12 18:34   ` Simon Marchi
2023-04-27 19:51     ` John Baldwin
2023-03-18  1:09 ` [PATCH v4 12/13] gdbserver: Read offsets of the XSAVE extended region via CPUID John Baldwin
2023-04-11 14:46   ` Pedro Alves
2023-04-11 16:25     ` John Baldwin
2023-04-12 19:11   ` Simon Marchi
2023-04-12 21:07     ` John Baldwin
2023-04-13 15:07       ` Simon Marchi
2023-03-18  1:09 ` [PATCH v4 13/13] x86: Remove X86_XSTATE_SIZE and related constants John Baldwin

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=4da73147-3fe8-ecf8-8133-5df102243b74@palves.net \
    --to=pedro@palves.net \
    --cc=aleksandar.paunovic@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@FreeBSD.org \
    --cc=simark@simark.ca \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).