From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id a01PHNEDKGVv7SsAWB0awg (envelope-from ) for ; Thu, 12 Oct 2023 10:33:53 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=default header.b=dNUWQkt4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 669BF1E0C1; Thu, 12 Oct 2023 10:33:53 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5549A1E00F for ; Thu, 12 Oct 2023 10:33:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C65343857702 for ; Thu, 12 Oct 2023 14:33:50 +0000 (GMT) Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A228A3858C5E for ; Thu, 12 Oct 2023 14:33:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A228A3858C5E 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 39CEXLsh013670 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Oct 2023 10:33:26 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 39CEXLsh013670 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1697121206; bh=FsM6cuaNYk64YnnIbd6tiIoHZZPizLb9p3hUtIZx3To=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dNUWQkt4tUDWP3KYj5e6aUp9jnsIIk3rxIukodOM7Vfdo1ASdhQxchHoaOXeDtSIu HRJwkMZbfo3p4L9nFQ3DbQgGLGDUpXcEPMyCR9wP6oyBMpMtQLJIEsfIHw1y/NdTNH C0Ac5PMPPaCdBAKgzA/7yLHnQqbFo0xHEk/erFj8= 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 4F3971E00F; Thu, 12 Oct 2023 10:33:20 -0400 (EDT) Message-ID: <1fe75b09-7531-4d57-845c-c4a172af17fe@polymtl.ca> Date: Thu, 12 Oct 2023 10:33:20 -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 14:33:21 +0000 X-Spam-Status: No, score=-3031.2 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org 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. Something I thought about: I think there are asymmetrical x86 processors now, with "big" and "little" cores, not sure how they call them. For them, is it possible for the XSAVE layout to be different per core, for instance some cores supporting AVX512 and some cores not? And therefore, will we eventually need to include CPUID / XSAVE information for more than one CPU core type in the core file notes? Simon