public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: gdb-patches@sourceware.org
Subject: [RFC PATCH 0/4] Handle variable XSAVE layouts
Date: Wed, 16 Mar 2022 12:46:04 -0700	[thread overview]
Message-ID: <20220316194608.89528-1-jhb@FreeBSD.org> (raw)

This is a first attempt at resolving the issue with XSAVE I described
previously.  There are more details in the commit logs, but here I think
will describe some caveats about the current prototype:

- It is probably terrible performance-wise to be reading the offsets
  from the target every time collect/supply_xsave is called.  I'd
  actually much prefer to store these (along with the total XSAVE area
  size) in the tdep.  The issue is that you can have gdbarches with the
  same tdesc that use different layouts (e.g. if you open a core dump
  from an Intel CPU on a host with an AMD CPU, the two CPUs could have
  identical XCR0 masks, but the layout in the core dump wouldn't match
  the layout of a live process).  Perhaps if I can fetch the offsets
  from the target in i386_gdbarch_init though I can iterate over
  matching arches looking for a match.

- The cpuid function I added in patch 3 isn't FreeBSD-specific at all
  (and would work on i386).  I could add it to x86-nat.c instead
  easily enough.  Even if OS's start providing a new ptrace op
  to fetch this info we probably should ship a cpuid-based variant as
  a fallback?

- The collect size I used in patch 3 for the XSAVE register set
  isn't really correct.  Really if I had the "real" XSAVE register
  set size available in the tdep (see point 1) I would not set
  REGSET_VARIABLE_SIZE and instead use tdep->sizeof_xsave for both
  sizes.

- I have no idea how gdbserver is impacted.  So far I haven't really
  found similar tables to i387-tdep.c in gdbserver.  (It's also harder
  for me to test currently as I haven't yet added FreeBSD support to
  gdbserver).

- I haven't added any support for fetching the offsets on Linux (the
  only other OS that supports XSAVE state currently).  I am waiting
  to have the design a bit more finalized before doing that.

John Baldwin (4):
  x86: Add an xsave_offsets structure to handle variable XSAVE layouts.
  core: Support fetching TARGET_OBJECT_X86_XSAVE_OFFSETS from
    architectures.
  Update x86 FreeBSD architectures to support XSAVE offsets.
  Support XSAVE layouts for the current host in the FreeBSD/amd64
    target.

 gdb/amd64-fbsd-nat.c      |  73 +++++
 gdb/amd64-fbsd-tdep.c     |   8 +-
 gdb/corelow.c             |  22 ++
 gdb/gdbarch-components.py |  13 +
 gdb/gdbarch-gen.h         |  10 +
 gdb/gdbarch.c             |  32 +++
 gdb/i386-fbsd-tdep.c      |  33 ++-
 gdb/i386-fbsd-tdep.h      |   6 +
 gdb/i387-tdep.c           | 592 +++++++++++++++++++++++++-------------
 gdb/i387-tdep.h           |  22 ++
 gdb/target.h              |   2 +
 11 files changed, 607 insertions(+), 206 deletions(-)

-- 
2.34.1


             reply	other threads:[~2022-03-16 19:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 19:46 John Baldwin [this message]
2022-03-16 19:46 ` [RFC PATCH 1/4] x86: Add an xsave_offsets structure to handle " John Baldwin
2022-03-16 19:46 ` [RFC PATCH 2/4] core: Support fetching TARGET_OBJECT_X86_XSAVE_OFFSETS from architectures John Baldwin
2022-03-16 19:46 ` [RFC PATCH 3/4] Update x86 FreeBSD architectures to support XSAVE offsets John Baldwin
2022-03-16 19:46 ` [RFC PATCH 4/4] Support XSAVE layouts for the current host in the FreeBSD/amd64 target John Baldwin
2022-03-17 13:17 ` [RFC PATCH 0/4] Handle variable XSAVE layouts Willgerodt, Felix
2022-03-17 16:20   ` John Baldwin
2022-03-17 18:03     ` John Baldwin
2022-03-18 13:49       ` Willgerodt, Felix
2022-03-18 17:27         ` 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=20220316194608.89528-1-jhb@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=gdb-patches@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).