From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AAA393858D1E for ; Thu, 12 Oct 2023 04:01:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AAA393858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 39C41CUZ005352 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Oct 2023 00:01:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 39C41CUZ005352 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1697083278; bh=DQy7UBQbZJ+ev5jr99QkLqxhK+XF3jhqmf5k1xkDFsc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=n1iods8oyMfZb9wO+Vf6SVBmNHFWgRzUqDbwKOerm9xqe56Gwef4xjhYJifLnBD/S Sfw1A6tGiH4dn9PYASuYdmLmrjtVxjA3FSRTG4SKZBYlVBw5StctZKv4CpC4BDA/St 3Y1Q3YUxSZ8YjIl6c1y0zCUltx79dyzWYJ0bh6W0= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3D09A1E00F; Thu, 12 Oct 2023 00:01:12 -0400 (EDT) Message-ID: <79fd06f3-a821-46d1-8f03-b91d1ad79ddb@polymtl.ca> Date: Thu, 12 Oct 2023 00:01:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note Content-Language: en-US To: John Baldwin , gdb-patches@sourceware.org Cc: Willgerodt@smtp.polymtl.ca, Felix , George@smtp.polymtl.ca, Jini Susan References: <20231009183617.24862-1-jhb@FreeBSD.org> From: Simon Marchi In-Reply-To: <20231009183617.24862-1-jhb@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 12 Oct 2023 04:01:12 +0000 X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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 2023-10-09 14:36, John Baldwin wrote: > One of the shortcomings of the previous XSAVE patch series is that it > depends on heuristics based on the total XSAVE register set size and > XCR0 mask to infer layouts of the various register blocks for core > dumps. This series introduces a new x86-specific core dump note > intended to supplant these heuristics by storing the raw CPUID leaves > describing the XSAVE layout in core dumps. > > This series proposes a new core dump note, NT_X86_CPUID (0x205), which > contains an array of structures. Each structure describes an invidual > CPUID sub-leaf containing both the inputs to CPUID (%eax and %ecx) and > the outputs (%eax, %ebx, %ecx, and %edx) in a format roughly matching > the follow C structure: > > struct cpuid_leaf > { > uint32_t leaf; > uint32_t subleaf; > uint32_t eax; > uint32_t ebx; > uint32_t ecx; > uint32_t edx; > }; > > This format is not XSAVE-specific and implementations could choose to > add additional CPUID leaves to this structure if needed in the future. > Consumers of this note should lookup the value of required leaves and > ignore any unneeded leaves. > > An alternate approach might be to write out a more XSAVE-specific note > that is an array containing the offset and size of each XSAVE region. > > Note that either approach would enable storing XSAVE notes in the > "compact" format at some point in the future. > > This series adds support for reading/writing the note to binutils as > well as suport for parsing and generating the note in GDB. It also > hooks this into both the FreeBSD and Linux x86 architectures in GDB to > read the XSAVE layout from this note when present, and to write out a > note when generating a core via `gcore'. I've done some limited > testing on FreeBSD/amd64 and Linux/x86-64, but it could probably use > some more testing on Linux in particular. (I know Simon has an AMD > machine with a layout not handled by the current heuristics for > example.) I suppose you are referring to this one, which has support for PKRU but where PKRU is not enabled (for a reason I don't know), leading to the total sizes being different (832 vs 896): XSAVE features (0xd/0): XCR0 valid bit field mask = 0x0000000000000207 x87 state = true SSE state = true AVX state = true MPX BNDREGS = false MPX BNDCSR = false AVX-512 opmask = false AVX-512 ZMM_Hi256 = false AVX-512 Hi16_ZMM = false PKRU state = true XTILECFG state = false XTILEDATA state = false bytes required by fields in XCR0 = 0x00000340 (832) bytes required by XSAVE/XRSTOR area = 0x00000380 (896) That machine's layout is handled by the heuristic since commit: gdb/x86: use size of XSAVE area of enabled features https://gitlab.com/gnutools/binutils-gdb/-/commit/054f25955c2b77f6e21073bfdd70a60e9df1ffe7 But anyhow, I can use it for testing. > For the gcore side, a new TARGET_OBJECT_X86_CPUID is used to fetch the > current note contents from a native target. There is still one gap > even with this patch series which is that if you are connected to a > remote target (e.g. gdbserver), we currently do not have a known XSAVE > layout to use when writing out a core via `gcore'. One option that > would close this gap would be to extend the remote protocol to permit > reading this new object from a debug server. The remote target could > then implement fetching this object and also make use of this object > to implement the target::fetch_x86_xsave_layout method which would > close that gap. Another possibility would be to just pick a "known" > XSAVE format that matches one of the heuristics. I think it would make sense to send the CPUID info over the wire. Can it be extra data in the target description XML? Otherwise, a new qxfer packet I suppose. If the current GDBserver doesn't support sending the CPUID info, I'm not sure I would make the remote target write a CPUID note based on a heuristic. It has pros and cons, we can talk about that when we get there. Simon