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 4F2463858C5E for ; Mon, 10 Apr 2023 21:00:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F2463858C5E 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 4PwLwh1Nw0z3Wc4; Mon, 10 Apr 2023 21:00:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4PwLwh0ftWz3mg3; Mon, 10 Apr 2023 21:00:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681160452; 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=jewY7eCY7wIfIY+k6ez00zJNrqmltp01QLVy1tQRBys=; b=Em3tzhfrw4RIhQlv0HVmsZ9nxTex16eWSFcJoZXMtLMeSs7bLUXcHwF/++bNGavgIGyRM3 x2ycP9wisgq64fWK1oNfvH/VF74FVQShAg+GChOMxGqLka8H05x6cOPux6rg/wgrWTrJ8I RDZvR3rphvBz5UeI2tnCNAdt5CCierg70ZuM1jjNVmXh5f4Ta7c6P9eAHPW2JIB9q9mOIT CJgy+Wi30H86z69SslpvcnRed0Wigpd6XJd4JqYOJJniJ3xi1VJI097h0YDInk+SgstqB+ PBLOiLnBQL3P+bHtTVbDSTwnKNQ+O6fnb5qBO8DcBWuSS5cmAVN8KRsM+nADUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681160452; 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=jewY7eCY7wIfIY+k6ez00zJNrqmltp01QLVy1tQRBys=; b=GDBwg8B/+r9uGi1M/SVTVRt8c3GyhYn6gKL7vFyG7AgEdavPFoq/yJnUf24aQH68vL/gJR fTreZHNx7sWr/PF9rVhowlBC7wsS69RHWSjqJOpVvtyBE6XCXUxvhFppaLAHC7WAsmYgXN MjO73w0ghIb4rTKxHoV52aeKzbx0Sx0ZBxaZigSjGmgbEIsrEPt0FPxyTX0x3IICMrNKNR C52gbK1b8LLv0T59ns0OnxlChwwQOkfotKMPivYkzRGt+cSTrLZLs96BM4M7PpgWrzAyUy DIbIVX/xEl6y4Mno66c7LdNFww5kiG2xUAKh6iMFwg3/pDqWPljur+VHiYv2/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681160452; a=rsa-sha256; cv=none; b=HKjxVAZ8IwOkxdTA7DQQVXRCkiMg89bjyS5/KrEAIKYrqFQGDANQNDXaY18ifocBuHjH19 ZhqEZV9lGebppjk5CW3YsE+TZ/NB/CO4LgQ+WH/WewaXvCI/wbkKBacFGPvfSE4krzjfUG +6JkpCK5yDpgdGnFCOFyCgwRWPmXOJz3+0aTvFXzWQj5/1m/M/m49G+zwTaO82ZUzXpDjB DuBdw6ir8chYvt4LIrxUiPVWqlfl2T4h+dUg7Ex/4B5G5nf+fq7BDVr1kZN3QhDIrtD0Ai 9R1JX877Qfo+t50i8p5rLEgjwp/qa5Uj5SgXlaP7iaKDnggXHlh9vRcqU4FBeA== Received: from [IPV6:2601:648:8680:16b0:542a:22bd:2c8e:f2bd] (unknown [IPv6:2601:648:8680:16b0:542a:22bd:2c8e:f2bd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PwLwg4xBZzfwW; Mon, 10 Apr 2023 21:00:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0b60c557-ac1e-28ef-4bd6-06064232371e@FreeBSD.org> Date: Mon, 10 Apr 2023 14:00:50 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20230318010905.14294-1-jhb@FreeBSD.org> <20230318010905.14294-5-jhb@FreeBSD.org> <68edcaf2-367c-231c-d3b9-4a5ddbc9463f@simark.ca> From: John Baldwin Subject: Re: [PATCH v4 04/13] x86 nat: Add helper functions to save the XSAVE layout for the host. In-Reply-To: <68edcaf2-367c-231c-d3b9-4a5ddbc9463f@simark.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,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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 4/6/23 12:40 PM, Simon Marchi wrote: > On 3/17/23 21:08, John Baldwin wrote: >> x86_xsave_length returns the total length of the XSAVE state area >> standard format as queried from CPUID. >> >> x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE >> extended regions from the running host. The total length of the XSAVE >> state area can either be supplied the caller if known (e.g. from >> FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host >> using x86_xsave_length. >> --- >> gdb/nat/x86-xstate.c | 65 ++++++++++++++++++++++++++++++++++++++++++++ >> gdb/nat/x86-xstate.h | 35 ++++++++++++++++++++++++ >> 2 files changed, 100 insertions(+) >> create mode 100644 gdb/nat/x86-xstate.c >> create mode 100644 gdb/nat/x86-xstate.h >> >> diff --git a/gdb/nat/x86-xstate.c b/gdb/nat/x86-xstate.c >> new file mode 100644 >> index 00000000000..7b42efe1266 >> --- /dev/null >> +++ b/gdb/nat/x86-xstate.c >> @@ -0,0 +1,65 @@ >> +/* x86 XSAVE extended state functions. >> + >> + Copyright (C) 2022-2023 Free Software Foundation, Inc. >> + >> + This file is part of GDB. >> + >> + This program is free software; you can redistribute it and/or modify >> + it under the terms of the GNU General Public License as published by >> + the Free Software Foundation; either version 3 of the License, or >> + (at your option) any later version. >> + >> + This program is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + GNU General Public License for more details. >> + >> + You should have received a copy of the GNU General Public License >> + along with this program. If not, see . */ >> + >> +#include "gdbsupport/common-defs.h" >> +#include "gdbsupport/x86-xstate.h" >> +#include "nat/x86-cpuid.h" >> +#include "nat/x86-xstate.h" >> + >> +/* Fetch the offset of a specific XSAVE extended region. */ >> + >> +static int >> +xsave_feature_offset (uint64_t xcr0, int feature) >> +{ >> + uint32_t ebx; >> + >> + if ((xcr0 & (1ULL << feature)) == 0) >> + return 0; >> + >> + if (!x86_cpuid_count (0xd, feature, nullptr, &ebx, nullptr, nullptr)) > > Does x86_cpuid_count return a count, as the name suggests (and not a > boolean)? If so, it should be == 0. Otherwise, ignore that. No, it returns a bool like x86_cpuid. Some CPUID leaves on x86 take a sub-leaf where the main leaf is specified in EAX and the sub-leaf in ECX when CPUID is invoked. The first CPUID leaves that used this documented the ECX input as a count (I think the first ones were used for enumerating cache topology info where ECX was basically an index). As a result, the APIs for CPUID builtins in GCC, etc. all use the suffix "_count" for the variants that take the ECX sub-leaf as an input. >> +/* See x86-xstate.h. */ >> + >> +void >> +x86_fetch_xsave_layout (uint64_t xcr0, int len, x86_xsave_layout &layout) >> +{ >> + layout.sizeof_xsave = len; >> + layout.avx_offset = xsave_feature_offset(xcr0, X86_XSTATE_AVX_ID); >> + layout.bndregs_offset = xsave_feature_offset(xcr0, X86_XSTATE_BNDREGS_ID); >> + layout.bndcfg_offset = xsave_feature_offset(xcr0, X86_XSTATE_BNDCFG_ID); >> + layout.k_offset = xsave_feature_offset(xcr0, X86_XSTATE_K_ID); >> + layout.zmm_h_offset = xsave_feature_offset(xcr0, X86_XSTATE_ZMM_H_ID); >> + layout.zmm_offset = xsave_feature_offset(xcr0, X86_XSTATE_ZMM_ID); >> + layout.pkru_offset = xsave_feature_offset(xcr0, X86_XSTATE_PKRU_ID); > > Missing spaces. Oops, fixed. >> diff --git a/gdb/nat/x86-xstate.h b/gdb/nat/x86-xstate.h >> new file mode 100644 >> index 00000000000..e9f5fb57e3a >> --- /dev/null >> +++ b/gdb/nat/x86-xstate.h >> @@ -0,0 +1,35 @@ >> +/* x86 XSAVE extended state functions. >> + >> + Copyright (C) 2022-2023 Free Software Foundation, Inc. >> + >> + This file is part of GDB. >> + >> + This program is free software; you can redistribute it and/or modify >> + it under the terms of the GNU General Public License as published by >> + the Free Software Foundation; either version 3 of the License, or >> + (at your option) any later version. >> + >> + This program is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + GNU General Public License for more details. >> + >> + You should have received a copy of the GNU General Public License >> + along with this program. If not, see . */ >> + >> +#ifndef NAT_X86_XSTATE_H >> +#define NAT_X86_XSTATE_H >> + >> +#include "gdbsupport/x86-xstate.h" >> + >> +/* Return the size of the XSAVE extended state fetched via CPUID. */ >> + >> +int x86_xsave_length (); >> + >> +/* Save the size and offsets of the XSAVE extended regions for the >> + running host in LAYOUT. Offsets of each of the enabled regions in >> + XCR0 are fetched via CPUID. */ >> + >> +void x86_fetch_xsave_layout (uint64_t xcr0, int len, x86_xsave_layout &layout); > > The function could maybe return an x86_xsave_layout. Ah, fair enough. -- John Baldwin