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 550A83858C33 for ; Tue, 25 Jul 2023 22:05:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 550A83858C33 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 4R9WLF4s70z4KMj; Tue, 25 Jul 2023 22:05:25 +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 4R9WLF47Z7z4KPG; Tue, 25 Jul 2023 22:05:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690322725; 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=IPQSd1Cs1V4M1pFw8zY9VhpYmBra9OsQrgdOI20/B9c=; b=N9adYKWHKz5FUynKXN8S6MeFj2P1d/7wLqpdLUxyEFKa1eUCjnU717lmEDO6BQkqS2d3wz gh2y5vAZr/vXPf4i1aHTwQe2+hjJFDtIy+rlq5nF8IdYa7lTZsUVVHKJ47AHEovJFhlxbV 864Dv1rxPONEgf7pwFEAUVIX2PlS6lYea7W/FDxFdDjnjZ6S/cn3Bmm7fZBydOxyNOgYzD jGWWFr9KitOyEHaLB/PAQV0jZqY69KxDwq10Hx85OdjV3781w5m3+ejSXYrnOv02Legqhw 8BOtuuaP3QhA2A+UqiL7Hp/j8s0EG46blQS3MTgB1jSipMNynQrurNMd2QuecA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1690322725; 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=IPQSd1Cs1V4M1pFw8zY9VhpYmBra9OsQrgdOI20/B9c=; b=CQsDofrod/VfxPvpEZ8JDrDFhAeY6MEGb37IZzc8MyIcaMlPnUQigqvQn3coNWFz6XH4fv eQw+OkKN7dJKwXEc7CDxaXc24W1SkH9cnOzutyuSFmFx3kj26m21PGFo/3frzq8eSHbZ8K AA1t5JOlb80GciT8qPaCIMLYu9PFz5otVfIev2PxY/mDLW/e+YnbWTBxO8cAb9NXzadcrp HxM7scSJbUsxWZeKpqyG+X4FZ3dFYUFo9wrA1INwiHAo0afSBLsSAYKad+8/d1Ay85QGB9 G00CoufIQZdjixPg3neeO/4GdqWuLdWv2tSFEk7oFrBP2nI0CRGhi/CqPEY8vQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1690322725; a=rsa-sha256; cv=none; b=WGzyqobm8wRWYW9B+/MhcbH6/ByXeejdEZrOU7mBQzK+XTyfsDL76DiILwsYnv/6JYg7eL 5tTqNYUQbF7gm15nxhhxg1TcftpatDJhdxiwQuEk5gsaEOoO+qizPSETW79dLEgUrce3t6 FdhAM8jIZRB/rmakvpCAqp0gJrPihWkGVXf6/XSzkZcv41AvgHNwO91i+SKdfDYMy6N0tV 57GtVBBhDGeuw2swP8o+QjEm3kXj1mVFfvP+03RYj72JpHH2Mzu7muqx2LLYLc+GkOJs2j Kv9qV8e/5G+6d+R27k6/KpPQ05EETXtD6FLHtDRUO43ScsvMG5FyUUWiLZMUng== Received: from [IPV6:2601:648:8680:16b0:5963:d3c5:f4f0:5523] (unknown [IPv6:2601:648:8680:16b0:5963:d3c5:f4f0:5523]) (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 4R9WLF1BCmzp0Y; Tue, 25 Jul 2023 22:05:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <08cce201-d044-cfcd-4147-6ea1f0eb0fef@FreeBSD.org> Date: Tue, 25 Jul 2023 15:05:23 -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 Content-Language: en-US To: Keith Seitz , gdb-patches@sourceware.org References: <20230714155151.21723-1-jhb@FreeBSD.org> <6a412964-2a25-da39-7c3b-38050437795a@FreeBSD.org> From: John Baldwin Subject: Re: [PATCH v6 00/15] Handle variable XSAVE layouts 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/25/23 1:42 PM, Keith Seitz wrote: > On 7/25/23 11:59, John Baldwin wrote: >> >> Hopefully it triggers the assertion, and then what will be useful is to see what >> features the tdesc contains ('info locals' would cover that if they aren't all >> optimized out). > > Yes, that assertion does trigger (on all -m32 targets). > > From the native-gdbserver/-m32 case at the assertion (I have a debug build): > > (top-gdb) info locals > tdesc = 0x197b410 > feature_core = 0x197d5a0 > feature_sse = 0x1987200 > feature_avx = 0x1989db0 > feature_mpx = 0x0 > feature_avx512 = 0x198a310 > feature_pkeys = 0x198aec0 > feature_segments = 0x0 > i = 0 > num_regs = 32767 > valid_p = 1 > __func__ = "i386_validate_tdesc_p" > (top-gdb) p *tdep > $2 = { = { > _vptr.gdbarch_tdep_base = 0xf5df38 }, > gregset_reg_offset = 0x159fb20 , > gregset_num_regs = 73, sizeof_gregset = 68, sizeof_fpregset = 108, > st0_regnum = 16, num_mmx_regs = 8, mm0_regnum = 0, num_ymm_regs = 0, > ymm0_regnum = 0, num_k_regs = 0, k0_regnum = 55, num_zmm_regs = 8, > zmm0_regnum = 0, num_byte_regs = 8, al_regnum = 0, num_word_regs = 8, > ax_regnum = 0, num_dword_regs = 0, eax_regnum = 0, num_core_regs = 32, > num_xmm_regs = 8, num_xmm_avx512_regs = 0, xmm16_regnum = -1, > num_ymm_avx512_regs = 0, ymm16_regnum = 0, xcr0 = 231, > xsave_xcr0_offset = 464, xsave_layout = {sizeof_xsave = 0, avx_offset = 0, > bndregs_offset = 0, bndcfg_offset = 0, k_offset = 0, zmm_h_offset = 0, > zmm_offset = 0, pkru_offset = 0}, > register_names = 0xf5a6a0 , ymm0h_regnum = -1, > ymmh_register_names = 0x0, ymm16h_regnum = -1, ymm16h_register_names = 0x0, > bnd0r_regnum = -1, bnd0_regnum = 0, bndcfgu_regnum = -1, > mpx_register_names = 0x0, zmm0h_regnum = 63, > k_register_names = 0xf5a900 , > zmmh_register_names = 0xf5a8a0 , > xmm_avx512_register_names = 0x0, ymm_avx512_register_names = 0x0, > num_pkeys_regs = 0, pkru_regnum = -1, pkeys_register_names = 0x0, > fsbase_regnum = -1, tdesc = 0x197b410, register_reggroup_p = 0x7a9578 > , > jb_pc_offset = 20, struct_return = pcc_struct_return, sigtramp_start = 0x0, > sigtramp_end = 0x0, > sigtramp_p = 0x7a99ae , > sigcontext_addr = 0x7a9c52 , > sc_reg_offset = 0x159fc60 , sc_num_regs = 16, > sc_pc_offset = -1, sc_sp_offset = -1, i386_mmx_type = 0x0, > i386_ymm_type = 0x0, i386_zmm_type = 0x0, i387_ext_type = 0x0, > i386_bnd_type = 0x0, record_regmap = 0xf5d5a0 , > i386_intx80_record = 0x7aa2fc , > i386_sysenter_record = 0x7aa2fc , > i386_syscall_record = 0x7aa2fc , fpregset = 0xf5b5c0 } Hmm, so what I have been assuming is that you only get a tdesc with those register sets if target::read_description (either x86_linux_nat_target::read_description in x86-linux-nat.c for a native process or the gdbarch_core_read_description handler in (i386|amd64)-linux-tdep.c) returns a tdesc with it, and the ones I just mentioned all set a xsave_layout at the same time. However, I think I had overlooked the remote target. That is, if you are connected to a remote target but want to use gcore to write out a local core dump, that I think is the case that is breaking. This case is a bit weird. I had assumed I could avoid having to send the layout across the remote protocol because the individual registers are sent across the protocol and gdbserver is required to deal with the layout and reinterpret the XSAVE "block" as individual registers. However, to write out a core dump note, we have to use some sort of XSAVE layout. I could either go back to making it a new TARGET_OBJECT and it could be fetched across the wire from gdbserver (but only used for gcore, not for anything else), but you still have a compatiblity problem in that old gdbserver's won't know about it so you need a fallback based on the XCR0 mask. Alternatively, we could just always use a fallback in this case of picking a layout based on the XCR0 mask. Previously this was always using the hardcoded Intel layout which is why this worked before. It's a bit of a shame to have to fetch it over the wire, but probably that is the cleaner long term solution, even though it will require a fallback for now to pick an arbitrary layout based on the XCR0 mask. -- John Baldwin