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 D84743858D39 for ; Fri, 28 Jul 2023 21:30:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D84743858D39 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 4RCLQT4lf7z3Q52; Fri, 28 Jul 2023 21:30:25 +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 4RCLQT42Q5z4CvK; Fri, 28 Jul 2023 21:30:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690579825; 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=UgKqs4fgXKHGX1Z/kyjDl96acQ4uJ3sgCbwxim/KEh0=; b=h7V34vOtAXEjPj9tn/AHvC1wuQ2zhibPQzmgjCpP+GGVINrBD65qZEfn6jYLcHMfCsWS7Z JLdkXOMopN5wV0skO/FgHzVeOY8/+B6mh2u1XIExPkq+e+0xNKefnZX+8K1ofGU9Kb9p8W 6cQ3ux1JUh3XwbxXiZ+1tA7Vk8GlOQP0E1zd2AKPgU9ZZJPKamXEdYn5MvDPiPgHLSAtaE 8ypObknJtN4DVW58hRbGdHy2E8v0cqZb7RIxIxJ5WU2td96Tv9fY4DmZY3dBa9MyFvYjwK qVhc0DVTxQ5zX4N1Kr92+VUBj1gNOsCiLPnTuOPBwJNZM8CQCPkOgG7FMzV62A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690579825; 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=UgKqs4fgXKHGX1Z/kyjDl96acQ4uJ3sgCbwxim/KEh0=; b=UDaXgUeZTxX2df303iwcfJ8R7n4+233yv3CywyhZsMI7QFdGfT2hLKRnrbxfFotMYdxxzn bdA9CHfkFtcgM/k8tS1DALwnESzBBVWNz8u+yJ53xaebGFyjNfGC3sLwCEaZ00+lEZpXjq PmdZ1cfn2NMxiRMNEWC8ZYbc2B8GBH4HxrLCO+P80KezLoxLPqYSHKTu1Y2Cum90T8/g9d AMDWLBAOQ+b3VSDXgprlG3E6TAkpyE0xJVI/Cofv27Dh8hopb/jgb8UoUX6/xpdzM9Mea+ fhJUOo2qMErrDxSsLrcojep9e1TABj6QmhJIxG8duqsTHD+6r+D9sxzCbrm3mA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1690579825; a=rsa-sha256; cv=none; b=UdJqLRxiUo5RhNUVv9n35zNTqa0ril6EemckA3zxK7pRBIHz4yEcsNIYqDCoo+2EBdHHWm ARhUIkIKs6hugzOGWSZixytnXSRyJeh0SVeUcM7vZoBP7fmdJq2QSUslVtTgcEHMFd9SGq zK+gj43ZYufj0UHdgx8pTswMQgl4eJkUXlt5qxcL/53IDV3v70J+bF7JxPcVW5m41LmSlM Qa4Ti/Czi/AgRDVkTMA/iYoqMRPpl2ZgcSw1ZY9ZkgmY1kvviBXuoXBeVNon9I3dAc4p4H uW66+ZjRud4bvO/ZTxWsdolgmvqE8XcOvTSAQ9BCG7lBvj/x/bFnh1Lj7lMLYw== Received: from [IPV6:2601:648:8680:16b0:a0f4:6ff:3266:ca96] (unknown [IPv6:2601:648:8680:16b0:a0f4:6ff:3266:ca96]) (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 4RCLQT1CClzGm5; Fri, 28 Jul 2023 21:30:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Fri, 28 Jul 2023 14:30:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v6 08/15] gdb: Update x86 Linux architectures to support XSAVE layouts. Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20230714155151.21723-1-jhb@FreeBSD.org> <20230714155151.21723-9-jhb@FreeBSD.org> <45c8bfbf-42d2-c9d9-d246-0ffd6fc4668c@polymtl.ca> <70fd2a39-f5a4-7188-dd8c-4e0eda971733@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 7/28/23 10:58 AM, Simon Marchi wrote: > On 2023-07-28 12:30, John Baldwin wrote: >> On 7/27/23 2:48 PM, Simon Marchi wrote: >>> >>>> Ooo, that's a good catch. This function is shared with amd64, so I think >>>> it's best if it keeps returning an xcr0 value, but we could patch >>>> i386_linux_core_read_description to instead do this: >>>> >>>> static const struct target_desc * >>>> i386_linux_core_read_description (struct gdbarch *gdbarch, >>>> struct target_ops *target, >>>> bfd *abfd) >>>> { >>>> /* Linux/i386. */ >>>> x86_xsave_layout layout; >>>> uint64_t xcr0 = i386_linux_core_read_xsave_info (abfd, layout); >>>> if (xcr0 == X86_XSTATE_X87_MASK >>>> && bfd_get_section_by_name (abfd, ".reg-xfp") != NULL) >>>> xcr0 = X86_XSTATE_SSE_MASK; >>>> >>>> return i386_linux_read_description (xcr0); >>>> } >>> >>> And i386_linux_core_read_xsave_info would return X86_XSTATE_X87_MASK if >>> it does not find a .reg-xstate section? >> >> Hmmm. It would need to do something like that yes. I realize I have a >> bug for i386-fbsd as well where it would return SSE when it should be >> returning X87. For amd64, both Linux and FreeBSD use FXSAVE (which >> includes SSE) as .reg2 (generic FP regs). For i386, both use FSAVE (which >> only includes X87) for .reg2, and Linux/i386 also has .reg-fxp that uses >> FXSAVE. This means that the "default" xcr0 value really should be SSE >> for amd64, and X87 for i386. >> >> I was considering returning a bool from the helper methods >> (i386_*_core_read_xsave_info yesterday (it makes the new gdbarch method >> implementations slightly easier to read IMO). Other options are to add a >> parameter to the helper that is the "default" value of xcr0 to use, or to >> return a value of 0 for xcr0 when no valid XSAVE info is found. Returning >> 0 is pretty close to the bool approach without requiring a dummy xcr0 arg >> in the gdbarch methods, so I think I'll go with that. >> >> In that case, i386_linux_core_read_description would go back to what it >> was in this patch, but the amd64 version would change slightly: >> >> static const struct target_desc * >> amd64_linux_core_read_description (struct gdbarch *gdbarch, >> struct target_ops *target, >> bfd *abfd) >> { >> /* Linux/x86-64. */ >> x86_xsave_layout layout; >> uint64_t xcr0 = i386_linux_core_read_xsave_info (abfd, layout); >> if (xcr0 == 0) >> xcr0 = X86_XSTATE_SSE_MASK; >> >> return amd64_linux_read_description (xcr0 & X86_XSTATE_ALL_MASK, >> gdbarch_ptr_bit (gdbarch) == 32); >> } >> >> Namely to add the 'xcr == 0' case. If that approach seems sensible I >> will post a new series since it touches both this patch and the FreeBSD >> one. > > I previously considered suggesting making the *_core_read_xsave_info > functions return gdb::optional, where they would have returned an > empty optional if the core does not have xsave info. The calling code > could then fall back to some other strategy. Returning 0 achieves the > same thing in a different way, it's fine with me (as long as it's > properly documented). I prefer that over the "passing a default value" > approach. > > If the changes only touch this patch, you can send an update just for > this one (instead of the whole series). It touches both this one and the similar FreeBSD one, so I've sent both. This patch (patch 8) also now contains one extra change from Keith's testing (testing sizeof_xsave != 0 to control use of .reg-xstate for i386) -- John Baldwin