From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.baldwin.cx (bigwig.baldwin.cx [66.216.25.90]) by sourceware.org (Postfix) with ESMTPS id 0C6BA394D881 for ; Wed, 16 Mar 2022 19:46:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C6BA394D881 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=FreeBSD.org Received: from ralph.com (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 62E7B1A84C6B for ; Wed, 16 Mar 2022 15:46:14 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Subject: [RFC PATCH 0/4] Handle variable XSAVE layouts Date: Wed, 16 Mar 2022 12:46:04 -0700 Message-Id: <20220316194608.89528-1-jhb@FreeBSD.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (mail.baldwin.cx [0.0.0.0]); Wed, 16 Mar 2022 15:46:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.103.1 at mail.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KHOP_HELO_FCRDNS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 19:46:17 -0000 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