From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uDLuNd/vD2YoYiQAWB0awg (envelope-from ) for ; Fri, 05 Apr 2024 08:34:39 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Tjg8NKEt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D70A61E0C0; Fri, 5 Apr 2024 08:34:39 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BFF001E030 for ; Fri, 5 Apr 2024 08:34:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8092D3846079 for ; Fri, 5 Apr 2024 12:34:37 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4C1C63846422 for ; Fri, 5 Apr 2024 12:33:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4C1C63846422 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4C1C63846422 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712320419; cv=none; b=i7uDwEkFmIwZYQIaabIXTJg0gSC28xHRX4qmLj/XSZVt8xBs0tdftf/Wbm4NFYdi4X0G37YoQMccaFX5HWEvkgzsxIgHbfn7YdKxNXNdledj+ooCFb727iPxFt8JoG6CX5emDDPa5gf6gpm9VUNpIN4kvMRchoAH9pc/rD6FGl8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712320419; c=relaxed/simple; bh=1/KLM7OtAU4SGu9fzhbr0wjMzX+XBNPecW5u7VD0d4U=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=ZJq3UsRGJEJMgvJUh1T1ttPpoBog4g1+LlWwN2PKl1u09stLTS1HxuYLbtZ8H07/LARQL25ozoUbVGwhOAcqNSlQCuuTtj/4+b44uGFmSUJFNL2kwcx8YjPX9u2pMxov6GqkbHiPz8ypYUwAnZ0642iRv7Qqa4hImfXFbV8FcoE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712320416; 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=xaPmnYZWw5WvJJUbtnYD7Rhqf61+jWaUsgDjlK3zliY=; b=Tjg8NKEtCzG3LY2NxjdAeefA3DzqwDBClHQ3hQKsO0rkwLnHShRtd8H2/xQmwk5jWaQ/CI Hac2qMg+e75Px1Oq+gSLMx0gcfwpNLbvs0NdmAut0OkusYpcmJMOHAcFqE68ePUR9z3NjF ZerXzkahjWA0XHcHg9i7dGHzwQysDjY= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-670-foV3ge-yPIG4GUHPQ3P1dg-1; Fri, 05 Apr 2024 08:33:35 -0400 X-MC-Unique: foV3ge-yPIG4GUHPQ3P1dg-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a450265c7b6so106549166b.0 for ; Fri, 05 Apr 2024 05:33:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712320413; x=1712925213; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B0gKIGW1TJktwqKV1G0vs2MfK/ZW+MlekLOPGT/H5lI=; b=S+BHzNsseFRY81YZ7+xh4vYASN3W1gFNxvfQQ9blbSkegokTrunVn6oYyq4iXYWcxf 4jGUc1YWbCd1BROmZTbGvsrhXSCDKeCapp6JV9pvC+lYnxE36xwKTF97CgzwvhdJErmG gimwZCYVck1PmtELwhxllKFRdsHZvTSdrJtxnsNdHdmfn7nhsRkMBfp1yFnfpuqISGzf lD7efXsUueS8DkMlXI5nB0WHcPmct+jMphp/2m1T1eIFu2xuUU3eidYo5rHd9RkngEqo YAAicvUcxfXRrGBJQ3y+gFa/s1W8b7qbcWxlTBmEOMBGHcuVY5IJ/XFztwrbl8TwWKOn Pywg== X-Gm-Message-State: AOJu0YwZY0GvzDDgehVMBl68gI12O08UqLlqZS9gU5qWsjVZZfA29r4k SJrQLYfTv2SNAXW/TpLP+c+sk7YZmfkZE4cGTnm+BpicpOaHScJ/dPVcJGWwgpAqnQWIYlKxiTI e9P5WPJGXWA8mlf1i+X0iju7Q5U71WWR3pvq42CsVo2rw1uADCBLuKD37PeJxt3+tpKfCvT/Q4u bDB/Ib8i0s0D4V4f4chCYJK+X0NwQ5BJ6hda7nFc8fKMA= X-Received: by 2002:a17:907:9611:b0:a4e:2189:d06b with SMTP id gb17-20020a170907961100b00a4e2189d06bmr1174054ejc.60.1712320413292; Fri, 05 Apr 2024 05:33:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IExb2myBUN2DV/CIBdlMLVFQnLJTfAp6XUNJNX99hVVMD5jn6OVwtzH9sy6vipp0wSwHvvmgA== X-Received: by 2002:a17:907:9611:b0:a4e:2189:d06b with SMTP id gb17-20020a170907961100b00a4e2189d06bmr1174031ejc.60.1712320412844; Fri, 05 Apr 2024 05:33:32 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id lv27-20020a170906bc9b00b00a51a67f08d0sm642298ejb.77.2024.04.05.05.33.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 05:33:32 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv4 05/10] gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition Date: Fri, 5 Apr 2024 13:33:15 +0100 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and gdbserver. This commit is part of a series that aims to share more of the x86 target description creation code between GDB and gdbserver. The I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target description creation, and I noticed that this constant is defined separately for GDB and gdbserver. This commit moves the definition into gdbsupport/x86-xstate.h, which allows the #define to be shared. There should be no user visible changes after this commit. --- gdb/i386-linux-tdep.h | 20 -------------------- gdbserver/linux-x86-low.cc | 21 --------------------- gdbsupport/x86-xstate.h | 20 ++++++++++++++++++++ 3 files changed, 20 insertions(+), 41 deletions(-) diff --git a/gdb/i386-linux-tdep.h b/gdb/i386-linux-tdep.h index 5891747572b..07593c6a8ec 100644 --- a/gdb/i386-linux-tdep.h +++ b/gdb/i386-linux-tdep.h @@ -58,26 +58,6 @@ extern void i386_linux_report_signal_info (struct gdbarch *gdbarch, /* Return the target description according to XCR0. */ extern const struct target_desc *i386_linux_read_description (uint64_t xcr0); -/* Format of XSAVE extended state is: - struct - { - fxsave_bytes[0..463] - sw_usable_bytes[464..511] - xstate_hdr_bytes[512..575] - extended state regions (AVX, MPX, AVX512, PKRU, etc.) - }; - - Same memory layout will be used for the coredump NT_X86_XSTATE - representing the XSAVE extended state registers. - - The first 8 bytes of the sw_usable_bytes[464..467] is the OS enabled - extended state mask, which is the same as the extended control register - 0 (the XFEATURE_ENABLED_MASK register), XCR0. We can use this mask - together with the mask saved in the xstate_hdr_bytes to determine what - states the processor/OS supports and what state, used or initialized, - the process/thread is in. */ -#define I386_LINUX_XSAVE_XCR0_OFFSET 464 - extern int i386_linux_gregset_reg_offset[]; /* Return x86 siginfo type. */ diff --git a/gdbserver/linux-x86-low.cc b/gdbserver/linux-x86-low.cc index eeeddcb9429..e8ef3667eb4 100644 --- a/gdbserver/linux-x86-low.cc +++ b/gdbserver/linux-x86-low.cc @@ -831,27 +831,6 @@ x86_target::low_siginfo_fixup (siginfo_t *ptrace, gdb_byte *inf, int direction) static int use_xml; -/* Format of XSAVE extended state is: - struct - { - fxsave_bytes[0..463] - sw_usable_bytes[464..511] - xstate_hdr_bytes[512..575] - avx_bytes[576..831] - future_state etc - }; - - Same memory layout will be used for the coredump NT_X86_XSTATE - representing the XSAVE extended state registers. - - The first 8 bytes of the sw_usable_bytes[464..467] is the OS enabled - extended state mask, which is the same as the extended control register - 0 (the XFEATURE_ENABLED_MASK register), XCR0. We can use this mask - together with the mask saved in the xstate_hdr_bytes to determine what - states the processor/OS supports and what state, used or initialized, - the process/thread is in. */ -#define I386_LINUX_XSAVE_XCR0_OFFSET 464 - /* Does the current host support the GETFPXREGS request? The header file may or may not define it, and even if it is defined, the kernel will return EIO if it's running on a pre-SSE processor. */ diff --git a/gdbsupport/x86-xstate.h b/gdbsupport/x86-xstate.h index 89c1143fbe1..11b37544aa3 100644 --- a/gdbsupport/x86-xstate.h +++ b/gdbsupport/x86-xstate.h @@ -120,4 +120,24 @@ constexpr bool operator!= (const x86_xsave_layout &lhs, #define I387_MXCSR_INIT_VAL 0x1f80 +/* Format of XSAVE extended state is: + struct + { + fxsave_bytes[0..463] + sw_usable_bytes[464..511] + xstate_hdr_bytes[512..575] + extended state regions (AVX, MPX, AVX512, PKRU, etc.) + }; + + Same memory layout will be used for the coredump NT_X86_XSTATE + representing the XSAVE extended state registers. + + The first 8 bytes of the sw_usable_bytes[464..467] is the OS enabled + extended state mask, which is the same as the extended control register + 0 (the XFEATURE_ENABLED_MASK register), XCR0. We can use this mask + together with the mask saved in the xstate_hdr_bytes to determine what + states the processor/OS supports and what state, used or initialized, + the process/thread is in. */ +#define I386_LINUX_XSAVE_XCR0_OFFSET 464 + #endif /* COMMON_X86_XSTATE_H */ -- 2.25.4