public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] i386: Use a fallback XSAVE layout for remote targets
Date: Mon, 27 Nov 2023 10:18:21 -0800	[thread overview]
Message-ID: <ac9344f6-6f9f-44a0-8f4e-0986f60a94f7@FreeBSD.org> (raw)
In-Reply-To: <ZWQdfCZoN5WED5Xs@adacore.com>

On 11/26/23 8:39 PM, Joel Brobecker wrote:
> Hello,
> 
> On Tue, Nov 21, 2023 at 02:22:18PM -0800, John Baldwin wrote:
>> On 11/21/23 2:09 PM, John Baldwin wrote:
>>> If a target provides a target description including registers from the
>>> XSAVE extended region, but does not provide an XSAVE layout, use a
>>> fallback XSAVE layout based on the included registers.  This fallback
>>> layout matches GDB's behavior in earlier releases which assumes the
>>> layout from Intel CPUs.
>>>
>>> This fallback layout is currently only used for remote targets since
>>> native targets which support XSAVE provide an explicit layout derived
>>> from CPUID.
>>>
>>> PR gdb/30912
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
>>
>> This fixes the regression for me locally.  It would perhaps be cleaner
>> to isolate the regression to the remote target by moving the new logic
>> in i386_gdbarch_init into remote::fetch_x86_xsave_layout.  The one
>> caveat of that is getting access to the right tdesc.  I could perhaps
>> change target::fetch_x86_xsave_layout to pass down the tdesc pointer
>> (or maybe the gdbarch_info?).  Alternatively it might be sufficient to
>> just use target_current_description() as the tdesc in remote.c?  It
>> wasn't clear to me if the relevant tdesc in this case was always the
>> same as target_current_description() (though I suspect it probably is).
> 
> I don't know if it would be cleaner, actually. Maybe safer in the sense
> that it would further limit the possible impact zone of your patch, but
> I thought the way you approached it was nicely general so that, if we
> had any other kind of target system that suffered from the same issue,
> we'd get the same fix as part of it.
> 
> Just my limited 2 cents, though. It could be that I'm seeing this
> from the wrong perspective, or misunderstood something...

Ok, I'm fine with using this approach but will ping Simon to see if he
has any thoughts since he reviewed the original series.

-- 
John Baldwin


  reply	other threads:[~2023-11-27 18:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21 22:09 John Baldwin
2023-11-21 22:22 ` John Baldwin
2023-11-27  4:39   ` Joel Brobecker
2023-11-27 18:18     ` John Baldwin [this message]
2023-11-27 19:30   ` Simon Marchi
2023-11-27 20:47     ` John Baldwin
2023-11-27 21:04       ` John Baldwin
2023-11-27 21:41         ` Simon Marchi
2023-11-27 21:09       ` Simon Marchi
2023-11-27  4:36 ` Joel Brobecker
2023-11-27 17:59   ` 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=ac9344f6-6f9f-44a0-8f4e-0986f60a94f7@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=brobecker@adacore.com \
    --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).