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 281133858D28 for ; Wed, 3 May 2023 23:45:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 281133858D28 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 [96.47.72.80]) (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 4QBYV53KXMz3jv2; Wed, 3 May 2023 23:45:33 +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 4QBYV52Ytbz4CX0; Wed, 3 May 2023 23:45:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683157533; 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=n6pXbgduBTbKM3TvqS5t8GNRgxozot8cy5mDyEOcpQ8=; b=JRM80rzEijJ8ehNgUBuWk8HFJvvsllfQXnjTpL7ktJ8Fi4fWED7m8EQ6y3PFIfbvitos3q LmoS4R8+Tzq+9zm06B1B5u9ddI5CcYvcEqbn63VbJ8itww9OBoAWlyuRPYuOuzXiUqOo73 DWhnp3xEc5LHUPKQoaMTEVQBjEWWnMzU8xKAcxIPbpHdhLCqSYHGql2Rd/3zZHZr6lRDiu Gvndz86K288E2TMq96l44bEUrdM57wWaXckKTW39BvvJM+1iLDosGpKWYkPG9dpwJKXE3P 4bdT+jnuU2sb6AXqedp16VHbNNiPjf/JEMeVWeh+qqGmm+5SP1C6vIoFnZXD5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683157533; 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=n6pXbgduBTbKM3TvqS5t8GNRgxozot8cy5mDyEOcpQ8=; b=yOKrhL9i07c8OwRNTNOf/zMAkmOQh2a9R8947YVdLk5JjvG+dQJXivDoqaR2KNVvO9zoR4 4JH57VgtZghdpj4IDuzMrjczoElJ77DNjjpg7ElPKNgEjgvBu+pC0kJClVupNSCNg4mLn7 3sQJL4pXhCCgAFXdFSpIUYaVIJGYpHJh/czOuioyrg+RZ5YcvQK7foHXfW08lEvuN04C0J UGmauhJx7XoA2vIJ7+W7F/16wTf61Yx6MArrfU/U53ON2d/WliynB0Ot4p+DY0EBcZbaIm WiQ/dRoIquHp+fqIRHbb+2NvCUC2gctXzUO3QUW5H1IOD6CisjiBPcIse2l+6w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683157533; a=rsa-sha256; cv=none; b=F2Gp88T4RwDL/AXg/vmILj+HEyhjchcpAyZKiLfr1jweC5DfofQqxCZjGAjKLW3hMOPCGG CyjCxU5G+RPCB83vJAhAvP2odWWc6oK4Rpu7rBGDecQERZJ0VpUicGvBk0nNb/0VnUjqUb esq4CRUNAQMBfy+PcURGljVBq1j8cgcw9WX0WqgWWNxlEeRMZxbDOdqQ1Gtkt/aaQ3PNtY 2kzPFBr5cS5a82tU7xR+4O2rwLtjSKwn25rpAJWxhSVFyZ3ib2baOjk0h7KzFe/hVpnBqS SPbIt2nUahvC/D49FP84gvVukzWoSPYPV0dd2prjKWLLrnJeA394TbAt266E2w== Received: from [IPV6:2601:648:8680:16b0:a5f2:2d0:1e3c:acb4] (unknown [IPv6:2601:648:8680:16b0:a5f2:2d0:1e3c:acb4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QBYV46k5bzvrL; Wed, 3 May 2023 23:45:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <98bf6cc8-f119-b9a9-aef6-94ee366f196c@FreeBSD.org> Date: Wed, 3 May 2023 16:45:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20230427210113.45380-1-jhb@FreeBSD.org> <20230427210113.45380-10-jhb@FreeBSD.org> From: John Baldwin Subject: Re: [PATCH v5 09/19] gdb: Update x86 FreeBSD architectures to support XSAVE layouts. In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-14.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 5/3/23 10:14 AM, Simon Marchi wrote: >> @@ -285,7 +291,9 @@ i386fbsd_core_read_description (struct gdbarch *gdbarch, >> struct target_ops *target, >> bfd *abfd) >> { >> - return i386_target_description (i386fbsd_core_read_xcr0 (abfd), true); >> + x86_xsave_layout layout; >> + return i386_target_description (i386_fbsd_core_read_xsave_info (abfd, layout), >> + true); > > Reading this gives me some questions. Just thinking out loud, nothing > necessarily actionable at the moment > > I found it strange that i386_fbsd_core_read_xsave_info fills an > x86_xsave_layout object that we don't use. We get xcr0 to generate an > appropriate target description here, and later we'll call > target_fetch_x86_xsave_layout (when initializing the gdbarch) to get the > x86_xsave_layout and save it in the i386_gdbarch_tdep object. I'm > wondering if, design-wise, this means that the target_desc object should > carry the xsave layout information. It would be saved in the tdesc > here, and i386_gdbarch_init would just get it from the tdesc. > > It's probably not as simple as that, since target descriptions are > transferred as XML from remote targets, and you still have to consider > older target descriptions that wouldn't include that information. But > I'm just trying to think what the ideal design would be. It's kind of odd as the layout doesn't affect the set of registers that are available (and today tdesc's are AFAICT just about which registers the target provides). The reason I extended the existing method that reads xcr0 is that I needed the section size along with the value of xcr0 to compute the layout via i386_set_xsave_layout and I was trying to avoid duplicating the code to fetch the section. I could perhaps change the function to return the value of xcr0 and the section size instead if that is less confusing? >> diff --git a/gdb/i386-fbsd-tdep.h b/gdb/i386-fbsd-tdep.h >> index cb991af9e49..f96c00d45eb 100644 >> --- a/gdb/i386-fbsd-tdep.h >> +++ b/gdb/i386-fbsd-tdep.h >> @@ -20,10 +20,16 @@ >> #ifndef I386_FBSD_TDEP_H >> #define I386_FBSD_TDEP_H >> >> +#include "gdbsupport/x86-xstate.h" >> #include "regset.h" >> >> -/* Get XSAVE extended state xcr0 from core dump. */ >> -extern uint64_t i386fbsd_core_read_xcr0 (bfd *abfd); >> +/* Validate and fetch XSAVE extended state xcr0 and extended area >> + layout from core dump. */ >> +uint64_t i386_fbsd_core_read_xsave_info (bfd *abfd, x86_xsave_layout &layout); > > I was a bit confused when I read the comment above for the first time. > Can you rephrase it to make it clear that the function returns the XSAVE > extended state, and fills LAYOUT? > > Also, what does "validate" mean, what happens if the thing we validate > is not valid? Hmm, the intent is "Validate and fetch xcr0 and the XSAVE layout". In particular, this does not return the extended state (which would be the value of all the AVX registers, etc.) but instead returns only the mask of enabled state (xcr0) and the layout of the extended area. If xcr0 does not appear valid or the section doesn't seem to have a valid size (i386_set_xsave_layout returns false) then the function claims that only SSE is reported by returning X86_XSTATE_SSE_MASK. That is the validation that "validate" is referring to. -- John Baldwin