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 1D37C3882061 for ; Thu, 17 Mar 2022 18:03:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D37C3882061 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 D5729785E2 for ; Thu, 17 Mar 2022 18:03:13 +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 4KKFPF10HGz4hpx for ; Thu, 17 Mar 2022 18:03:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647540193; 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=jdCbYlF0ybLVfyV5rf4V12wotZAlpmbAfed2RSgblaU=; b=a8MRT0PsykDSS6qt4fq44zF/Pno83V+4h7X5iAtnrl/OS/w5HxIW/dIpA0WJiGQx2TN1kc ogWE4UGmeB5MFZOot1hF7iqET4wutEhEyem/wKwTcVWK2wDURA4n1s9Y54raKIW5Sm8DEJ HQBkIrPOkwFjLev8j3smR9C80BKhkTkDic83QCn1A5mcksmlQpwXV6bcoQoudgKzcxlxVv U0wS7793TqD9lbbueEUkv+EVroix4OraoHhnFig4nF5/3tOI8dvSJ49vegLsqKMYssHzPP udgIRNIVxhkq42rTC8Xrn9Crz484mL2xedOkDNsD/U9HFza/Qk+gTI4l+CLKrA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 70E77ABF4 for ; Thu, 17 Mar 2022 18:03:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 17 Mar 2022 11:03:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: gdb-patches@sourceware.org References: <20220316194608.89528-1-jhb@FreeBSD.org> <8e08b537-fe97-3c06-58d0-1e41cded2054@FreeBSD.org> From: John Baldwin Subject: Re: [RFC PATCH 0/4] Handle variable XSAVE layouts In-Reply-To: <8e08b537-fe97-3c06-58d0-1e41cded2054@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647540193; 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=jdCbYlF0ybLVfyV5rf4V12wotZAlpmbAfed2RSgblaU=; b=n9fH8Sh7onBV9NPX8TmdIuTuSw/jb+lBAh2tGgiEornezxILuwG+H5Z+W3mbVqM4S8YkZz gpveaQnybDVLVmZm2lJNFZFNsF1aUSHKBXdQRLZsjYpW6GA/kD7oLjzuT8H8USqxiMSaJy mD7Z+xajWasHLoj9P+F+KOIA+a2DY6T1LD0qcwlctFx0nKRMAPa2qxT7hRlfKNoCGDK1qw 2lMfBh0BWumISULKW6MfMbstp92h1jj1PJShSXppUbLS6BRwp5d0UyPai6xnRxLlzfcALN eu7IsU+aGOF7SNk5VxezMDI1ni+E4l0zAbU5pVCyfbcPB4F/f1qM8XIu3ze/8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647540193; a=rsa-sha256; cv=none; b=nnJzsWdSqFr2cwwUPCE8QgObyDhGprUBmVoSe99nWu5fnif5NiDW++2LVn1IE5EX0QfiHg ezbIz2FsJ2CIbg+z4pcMjAZNrZjXYvWryRelyP8NLquF8P72/FZztfzf8DZVTiARrO7anB PZnOlxEUoLF0eGWklTnnkcCT5L1N+OjxMdqngObJxzZdz76Fj0vhK+QkZ9pXrU8Ssx00xE IoVf4oa7TYRIqiI74c9uCnPoKmHmnbB+DpyKiSa1ohzZEm70pNBwZwXycrjWsr1ffnnW0j KoYlNcFFJjwLdhsmRm7/CKIfJrmZFFMdUnjPRgnJKtF4Hzv/341LYpBYj6pr6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-4.5 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2022 18:03:15 -0000 On 3/17/22 9:20 AM, John Baldwin wrote: > On 3/17/22 6:17 AM, Willgerodt, Felix wrote: >>> This is a first attempt at resolving the issue with XSAVE I described >>> previously. There are more details in the commit logs, but here I think >>> will describe some caveats about the current prototype: >>> >>> - It is probably terrible performance-wise to be reading the offsets >>> from the target every time collect/supply_xsave is called. I'd >>> actually much prefer to store these (along with the total XSAVE area >>> size) in the tdep. The issue is that you can have gdbarches with the >>> same tdesc that use different layouts (e.g. if you open a core dump >>> from an Intel CPU on a host with an AMD CPU, the two CPUs could have >>> identical XCR0 masks, but the layout in the core dump wouldn't match >>> the layout of a live process). Perhaps if I can fetch the offsets >>> from the target in i386_gdbarch_init though I can iterate over >>> matching arches looking for a match. >> >> I don't quite understand why storing them in tdep wouldn't work. >> We get XCR0 from the coredump, not from the CPU analysing >> the coredump. For live targets we would query CPUID on GDB/gdbserver. >> I don't see how this would clash in your example, but maybe I missed >> something in your patches. > > The problem is that two tdep's with the same XCR0 value currently > have an identical tdesc and thus share the same 'struct gdbarch'. > However, an Intel CPU with XCR0 of 0x207 uses a different layout > than an AMD CPU with an XCR0 of 0x207. We would thus need separate > gdbarches for those. I think though I can make that work if I fetch > TARGET_OBJECT_X86_XSAVE_OFFSETS in i386_gdbarch_init() before this > loop: > > /* If there is already a candidate, use it. */ > arches = gdbarch_list_lookup_by_info (arches, &info); > if (arches != NULL) > return arches->gdbarch; > > And instead only return an existing gdbarch if it has the same XSAVE > layout. For example, RISC-V does the following logic to handle > differences in gdbarches that aren't fully handled by the tdesc: > > /* Find a candidate among the list of pre-declared architectures. */ > for (arches = gdbarch_list_lookup_by_info (arches, &info); > arches != NULL; > arches = gdbarch_list_lookup_by_info (arches->next, &info)) > { > /* Check that the feature set of the ARCHES matches the feature set > we are looking for. If it doesn't then we can't reuse this > gdbarch. */ > riscv_gdbarch_tdep *other_tdep > = (riscv_gdbarch_tdep *) gdbarch_tdep (arches->gdbarch); > > if (other_tdep->isa_features != features > || other_tdep->abi_features != abi_features) > continue; > > break; > } > > if (arches != NULL) > return arches->gdbarch; > > I think it would also be handy in this case to extend the xsave_offsets > structure to include the total size that can be used in the collect/supply > callbacks. I have made these changes and it does appear to work. I do think the approach of a new TARGET_OBJECT will work (and it will support adding a new NT_X86_XSAVE_LAYOUT or the like in the future to better support core dumps). If you agree with that part of the design (and storing it in the tdep, etc. I can try to merge in parts of your patchset (in particular, moving some things to gdbsupport and similar gdbserver patches) or I'm happy to let you drive. I will send a V2 with the changes to store the layout in the tdep. -- John Baldwin