From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id DA8D03858D33; Tue, 17 Oct 2023 00:04:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DA8D03858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DA8D03858D33 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2610:1c1:1:606c::19:2 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697501099; cv=pass; b=ugWy9cMFF4os6TBteSJkEzzC8yauho4CKeITCpTZ3IAMSRJDQEIn7rbftXmg1sBWqLZtV1LgxS5m8duGpcJSwxXWAm0WSkFXaO2Wz04zAj/3zygti25bXov8v0lHuIJr8i6d570NfLHs2eAuGedS1ZYdbLS7xnb8TjtZ7SkBDi0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697501099; c=relaxed/simple; bh=X0Ot2U7cOGIZyzY8wtomTqoSZH/F4LpRatG3Te9nLQM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=C14rVoE+sDzkO8Vk92h7KY/5DSKXm5zqsgsBHB2voHOCLCj1jtHvBpVRXnHLobbq8XgRCSrE4VvQ5gdXScwhXDY+q3uzjOfFtoUAbU2iN2FGPF/UeMbMYGI/w6aUnJ1RVwzgC/ejoq6jRyR6hWcTLQ+l1jSLmUDe9X+/hfk4C/E= ARC-Authentication-Results: i=2; server2.sourceware.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 4S8Z3q0kpXz3bFn; Tue, 17 Oct 2023 00:04:55 +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 4S8Z3p6tJNz3Jp8; Tue, 17 Oct 2023 00:04:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697501095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tXIAuDZCmjoYP7XvxxthWQGsP1EV3fDibxzyK7v042w=; b=qaNJZm+5Uol8NMYrHT65L5VbQKW3bMjgs2vH5wbB0D6ZKtKmxwB/g1A31vKckp7ohSt/2i XJCIXNI7R/c8BV3it8MnnQL4k0ykdo2vnhZ5XoTEdIrkLMN7956y29l8uW5h19QG/AcGnV nieZhA46puxEo4hOBpOXdzhqsqDfJer9CwhpYGLwunbVFXZfZTCNM/zCG0/Uo2NwGLNVx6 PcGlaeAzCYeow7lgsSpND7ewluBF8wj7zAx99zkHkY2lg5E9OhF+lWJtlIV9uZRP4lFrWN plKyYYSCJ6TsQIV0tZV48cL63C2xf7o1YSmjpxeLuhMkSgBQPppmAGMQ1pMU0g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1697501095; a=rsa-sha256; cv=none; b=xUExQu6cq98k1a11zUB+WsQmMWNTs789/4VKC6K9MEwHiV5YMhk0+mUtX+8fzZ5bjRy3iZ A1ws52APfUf+q1ECUtq/CdEgHcRypm45250K09YID9nKSUcMjKSNucXspsG+lH+Jx01Wuq Qx9G4fR/eLxfDfh8g8UwNfRpN1SzX3siq8mSKPe1txlMSlDaa5Eey2PXOco76nEKCWF9Lb J4+G+Z9YpggpfXPWbjrVZOICwKAtmeVIbENOu+Wnwrz4pZHezPErcW8OCa3OmcTwzBmdaA Lt0PmJTuNEj3ZNo0KTqyOm6KzPcdweXYa/Cg/ujlatJAYZr9hge9dzKHiG9d2Q== 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=1697501095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tXIAuDZCmjoYP7XvxxthWQGsP1EV3fDibxzyK7v042w=; b=nHvzDKWdah2oTg4UCkO9kkoOoRbPP6r9aHj92U7p3rtdcK5XrBa2d/G+WkyyU8pgQjG0vP J9Lexj1POYIQD3ZnNCQfl0/ZGxRAxAKmO7Vn1WyX+fED8GMlogn0jhMVqOWJRtiggE7CkT JGm6GmNTFreOt/idoB8/mZqqbcnDOCks9fSrkgR/FJW+o7ASxLeirMwqMl3qyo8/mbFjKD Pwgxeg2B8CnR6lwC/G3q+Gp3jbI5qkP4/BC8+b9Q95Ds+eFKKEwKh2PwaXVDE1Y3sxvI3P cnbRajPSSzDDUSk6BRH8xlScpUQkeVjLK0/U+KCBbnZBi00VUBrIZ/gPwenT7A== Received: from [IPV6:2601:648:8683:39a0:f055:f679:76c4:bebe] (unknown [IPv6:2601:648:8683:39a0:f055:f679:76c4:bebe]) (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 4S8Z3p0wCDzv7n; Tue, 17 Oct 2023 00:04:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <2de96e9c-a78a-fedf-bb18-5bca186a05af@FreeBSD.org> Date: Mon, 16 Oct 2023 17:04:53 -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: [RFC 02/13] i387-tdep: Add function to read XSAVE layout from NT_X86_CPUID Content-Language: en-US To: Lancelot SIX Cc: gdb-patches@sourceware.org, Willgerodt@sourceware.org, Felix , George@sourceware.org, Jini Susan , Simon Marchi References: <20231009183617.24862-1-jhb@FreeBSD.org> <20231009183617.24862-3-jhb@FreeBSD.org> <20231016091732.ybyjym67r2l7e3ol@octopus> From: John Baldwin In-Reply-To: <20231016091732.ybyjym67r2l7e3ol@octopus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.6 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,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 10/16/23 2:17 AM, Lancelot SIX wrote: > Hi, > > I am not familiar with XSAVE details, but I have pure c++ style comments > below. Thanks, I've generally accepted the changes aside from a few modifications below. > On Mon, Oct 09, 2023 at 11:36:04AM -0700, John Baldwin wrote: >> This can be used by x86 arches to determine the XSAVE layout instead >> of guessing based on the XCR0 mask and XSAVE register note size. >> --- >> gdb/i387-tdep.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++ >> gdb/i387-tdep.h | 8 +++ >> 2 files changed, 140 insertions(+) >> >> diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c >> index 47667da21c7..1eac2b6bd2a 100644 >> --- a/gdb/i387-tdep.c >> +++ b/gdb/i387-tdep.c >> + size_t size = bfd_section_size (section); >> + if (size == 0 || (size % (6 * 4)) != 0) >> + return {}; >> + >> + char contents[size]; > > If I remember correctly, VLAs are not a C++ feature (but are supported > as a GCC extension > https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html). I am unsure > if GDB has a policy regarding the use of extensions, so maybe this is > fine. Otherwise, you could use a std::vector instead (it comes with a > dynamic allocation, but I am not too concerned at this is hardly on a > performance critical path) > > std::vector contents (size); I've used a gdb::byte_vector instead of a plain std::vector<>. >> + if (map.count (cpuid_key (leaf, count)) != 0) >> + { >> + warning (_("Duplicate cpuid leaf %#x,%#x"), leaf, count); >> + return {}; >> + } >> + map.emplace (cpuid_key (leaf, count), >> + cpuid_values (eax, ebx, ecx, edx)); > > As Simon pointed out, there are two lookups here, where you can get away > with just one. However, this is C++17 only which is not [yet] available > in GDB. Instead, you can use the value returned by emplace to know if > an insertation has been done or not: > > auto emplace_result = map.emplace (cpuid_key (leaf, count), > cpuid_values (eax, ebx, ecx, edx)); > if (!emplace_result.second) > { > warning (_("Duplicate cpuid leaf %#x,%#x"), leaf, count); > return {}; > } I'm going to assume that C++17 will land first in GDB before this and just go with try_emplace for now. If I end up backporting this to GDB 14 (which I don't currently anticipate), then this wil be nicer for that. -- John Baldwin