From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 2D4F7385828D for ; Wed, 27 Sep 2023 20:20:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D4F7385828D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4Rwnzv0zCWz4stV; Wed, 27 Sep 2023 20:20:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rwnzv08q4z4MSG; Wed, 27 Sep 2023 20:20:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695846043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lnD6cZX+iXndf+e1JAscCL/NF4ELVYYu/EQ3IMLMlMM=; b=gZHz5f7M6XzyTB2HNxXJ7DKey2miLth9zWHVPqhfCfm9/Fntz987Ylx75BlA8hGjaSbry7 umN0EmiktbKoHcob6jZGm9pHYDr/amEl+Ete5L48wQ1SMyY7+g4BnMA8/m42A36SYlvJo5 xUXMaGeJdgmtJCS8Euh/VCTrCGFuaSIMMgR5wtEDWRkjNiKPclJYUo6KlJdKcJMZMWNDLq j8LBrwX9cnUp5wgf4+EszMxcUmtUhdJEP2IwraiEqISGIcq6ScnIdeiH8jtTjVzEAaaVr4 S/vqJYL78JsGpMeIfsoiyZCxvVlojLvh/A6is8HEFJve0kHCIKRy3uYiIFqrsg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695846043; a=rsa-sha256; cv=none; b=OLT75lkOprHQ2lsDIP3uXJb3ZYoTvZ35/iaquOS7XZ2qLEtijqsCB/YRCNTw78GN2yG0sZ 71afapQgO/WJh1cPywamUy/3GiOWFZx/AcJg84Ng4FV1+GYSoxdGsaj8dXM1ILyGD4K6kF l//9jhnqqIxxPdLBoCycglV1IlHmFpRE1s6MahCrFgqsYBjf7NFaqFOQNUbLjlMR8kLopF AHaq0KjrOjalWpPgXbGv1nvpHiiMIVKHdv2LZKck1HjskYF1D7QlsBRzAlZqbzRRH9oQY7 lD++qhxo0xsa4GzKtnjaqcJdS79ss42h0fdd63xA6dHZ5cH8jmnqJWZGDyCusA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695846043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lnD6cZX+iXndf+e1JAscCL/NF4ELVYYu/EQ3IMLMlMM=; b=tGGLoxKY+u8uuhWh+h7O6hJGasNFIoj5FOqceF69p/ID4giKKGXoW1Xr+kl8PO0AbrHEmz NpcvH9wMgZv8ZmzUzbXS7SE917l/VfHE8YmZotOT56njuYDY8wzYkZQqpnvtwPhvgiEfmC djr4n6CWHRzPTRzmwkv6fqa1tbfAqWRwBrTbzWFzOpBp28yBU7z3L/SU1s9JKO9GIweM4/ V5C3LiyDvpIz69vkkL8GvnP6s3L+Wt2KrMiCmlJqLEqQUxLXe8nmOsWFnm9QlauFwea0yJ huBElMG5gR+LM5wqJNXP0MlC/zllON/PiYEw7OlJLU+c3U+yQINcQApI/WDE9A== Received: from [IPV6:2601:648:8683:39a0:7c2a:d4a:3730:4e68] (unknown [IPv6:2601:648:8683:39a0:7c2a:d4a:3730:4e68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Rwnzt4P02z1HWk; Wed, 27 Sep 2023 20:20:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0e287e21-57a8-11a6-8cdf-60cb34510129@FreeBSD.org> Date: Wed, 27 Sep 2023 13:20:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] gdb/x86: use size of XSAVE area of enabled features Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20230927161525.3546855-1-simon.marchi@polymtl.ca> From: John Baldwin In-Reply-To: <20230927161525.3546855-1-simon.marchi@polymtl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/27/23 5:15 PM, Simon Marchi wrote: > Since commit b42405a1594 ("gdb: Update x86 Linux architectures to > support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD > Ryzen 3700X machine: > > FAIL: gdb.base/gcore.exp: corefile restored all registers > > The test gets the register state (saves the output of "info > all-registers"), saves a core with the "gcore" command, loads the core, > and checks the register state against the one previously saved. The > problem is that when reading registers from the core file, the last half > of ymm registers is unavailable: > > (gdb) print $ymm0.v32_int8 > $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, } > > One strange thing with this machine is that the bitset of state > components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU", > but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX". So, PKRU appears > to be supported by the processor, but disabled by the kernel. I didn't > find why yet. > > From CPUID leaf EAX=0Dh, ECX=00h, GDB can get: > > - from EBX: max size of the XSAVE area required by features currently > enabled in XCR0. On my machine, it's 0x340 (832). > - from ECX: max size of the XSAVE area required by all features > supported by XCR0. On my machine, it's 0x380 (896). > > At runtime, GDB uses ECX (max size required by all supported features) > to fill the x86_xsave_layout::sizeof_xsave. So, when writing the core > file note for the XSAVE state, it writes a note of size 896, even though > it doesn't write the PKRU state. When loading back the core, GDB tries > to figure out the layout of the XSAVE area based on what features are > enabled in XCR0 and the size of the note (the size of the XSAVE area). > Since my combination of XCR0 and size of XSAVE area doesn't match any > combination known by GDB, GDB falls back to a gdbarch supporting only > x87 and SSE. > > This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave > field (and consequently the size of the XSAVE state note in core files) > using EBX, the size of the XSAVE area required by currently enabled > features in XCR0. This makes i387_guess_xsave_layout recognize my case > with this condition: > > else if (HAS_AVX (xcr0) && xsave_size == 832) > { > /* Intel and AMD CPUs supporting AVX. */ > layout.avx_offset = 576; > } > > In other words, just as if my machine didn't support PKRU at all. > > Another reason why I think this change makes sense is that XSAVE state > notes in kernel-generated cores on this machine have size 832. So this > change makes GDB-generated cores more similar to kernel-generated ones, > reducing the diversity of XSAVE state notes that GDB needs to be able to > figure out. > > Note that if PKRU was enabled on my machine, then the effective XSAVE > area size would be 896 bytes. We would need to add a case in > i387_guess_xsave_layout for that combination, since there is no > currently. But I don't have a way to test that right now, since I don't > know why PKRU is disabled. > > Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85 > --- > gdb/nat/x86-xstate.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gdb/nat/x86-xstate.c b/gdb/nat/x86-xstate.c > index 9fdc572356ab..5ae014af4f49 100644 > --- a/gdb/nat/x86-xstate.c > +++ b/gdb/nat/x86-xstate.c > @@ -42,11 +42,11 @@ xsave_feature_offset (uint64_t xcr0, int feature) > int > x86_xsave_length () > { > - uint32_t ecx; > + uint32_t ebx; > > - if (!x86_cpuid_count (0xd, 0, nullptr, nullptr, &ecx, nullptr)) > + if (!x86_cpuid_count (0xd, 0, nullptr, &ebx, nullptr, nullptr)) > return 0; > - return ecx; > + return ebx; > } > > /* See x86-xstate.h. */ > > base-commit: 4befded43f524d0840bb88fff7b77415b73a3851 Reviewed-By: John Baldwin One further note is that the Linux x86 arches use x86_xsave_length() to infer ("guess") the size of the XSAVE register set that the Linux kernel writes out in core dumps. On FreeBSD x86 arches, GDB is able to query this size directly from the kernel via ptrace. My use of ECX for this guess earlier was just not the best guess. In the case that the kernel enables all of the available features, then ECX and EBX have the same values, so this only matters for a system where the kernel has enabled a subset of available XSAVE extensions. -- John Baldwin