From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7CFD0386F81E for ; Sat, 11 May 2024 10:08:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CFD0386F81E 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 7CFD0386F81E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715422136; cv=none; b=hgG3qlxukowkDyojI8pgsQGILl+W1sHVspBsAAtwlo4wxjHT19ZDDpuWI+LGlgTTHtiDcjb/jYv3Enurq2aHWsYidraJ6rA4lSyKft1zOohAvjWRCx1fuCwDPuyu2CvGqSQd8QqF2XWEZ4GaKhQT9Kz9egG7R+T42A92HtyfsOw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715422136; c=relaxed/simple; bh=MFgkr532Vi1oxUH9FpQkfHy1s0OzaiisKgMIJpYjTQQ=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=FhOmV4wFMl+fU57TlUUuPJybvKOMGXxm+hlfof9rkDZIzWMyv9y3cJe7v5Sz1LP/a2R83cr7dSkj4VxcG3SNvxKXFO3klCClxp8I0EtPjAk+/u3t4s+I9V9grtjKAMCw8aZSBGKhnw5NYC/OVe2jP92WxFuUkgIr5vVHq0pt4KQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715422134; 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=lC2Tq99AW3TJB6pG4mmMEfX6GhhMEKdgIbk1jbDcgf8=; b=g3DtDoghWN0Y+UavWj1cWVw60jxdqp0gsWGYO1on5qCLJviWauJy5w+iZr5QxzU/RWznH+ Z6iYK8BypRObJ12UYIfWWAxTJlK/jWOsHKBt3AiCgAVnMcER4kjTMPHza+opF/4IavCXDk nU4YgoCylUD4zwYYwP+LCmm9PsektN8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-355-iQ1pa8zrOPSgZxKF3tXFug-1; Sat, 11 May 2024 06:08:48 -0400 X-MC-Unique: iQ1pa8zrOPSgZxKF3tXFug-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-41ffa918455so7020485e9.3 for ; Sat, 11 May 2024 03:08:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715422125; x=1716026925; 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=lC2Tq99AW3TJB6pG4mmMEfX6GhhMEKdgIbk1jbDcgf8=; b=B1hGdVwPNNQzFVAqK6qagoDtLe/ZyM6StGWpAHYsL/Ualq+ZCE3d7WIKkCnuyfIvOR 1lUOjy+yAfkqSRdN9ECQykNS0/8IbVe5STSjRbD3wAE5X4D7J4E1oyjxPPY344oGkqHf 7SyAxeB1ACne9gvx5LPP3a8AGwWQQMl/CZX+F2dBgSt+bPRkqDaa0TFDvyPu1sNSu+LE Um0wtLlCIi6RwuzRO66XHgH4wSfagMejN1XP3z9bXWaHeazAZkikREitd8+zuzUA1j8S 8YYak5XcUjJkokUxKbHACKQv/yB6ie1AAf0cUG8WXoBkER+K7Tggeli+ifWU4Qh9yCJp q/XA== X-Gm-Message-State: AOJu0Yz4cOABqSU61f36ztm8ILytwTcA+9fV67CHd9SgPJ1Klzwdo0ud 33Hb04fWiKwlkOhka5vsKR+JIztQ6fwfG0UmVskRuOWUPusPuxbBiZjKf/CJY0DNJBW5LJoYP3G iGjNXYdSrlgEZdZuCPMORqUBl3+2Vo08siBuCC86bLELy19deMZXCZFG9kmJIrngxkeb/5ZNFv2 ujeXkUBRLzJ0bzLpzvttfQgyNZpAXK3kVVsPmeuuxuCU8= X-Received: by 2002:a05:600c:4ba2:b0:41a:9fc2:a6b1 with SMTP id 5b1f17b1804b1-41feaa4352amr36781815e9.22.1715422125422; Sat, 11 May 2024 03:08:45 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGJepKyWXQ2qFLVH3JMcW9juYU7DW6bwXpzizyNUY5kd7QJn6JnXpf9dqnU2eWAARkYwu3Spg== X-Received: by 2002:a05:600c:4ba2:b0:41a:9fc2:a6b1 with SMTP id 5b1f17b1804b1-41feaa4352amr36781635e9.22.1715422124760; Sat, 11 May 2024 03:08:44 -0700 (PDT) Received: from localhost (92.40.185.101.threembb.co.uk. [92.40.185.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-420111f2decsm8363625e9.22.2024.05.11.03.08.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 May 2024 03:08:44 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess , felix.willgerodt@intel.com, jhb@FreeBSD.org Subject: [PATCHv7 0/9] x86/Linux Target Description Changes Date: Sat, 11 May 2024 11:08:30 +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=-1.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_ABUSEAT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: In v7: - Patch #3, based on John's feedback I've moved the have_ptrace_getfpxregs global into an i386 specific file within the gdb/nat/ directory. There's some tweaking of includes as a result, but nothing much really changes. I agree with John that this was probably the right thing to do. - Patch #4, the v6 patch broke the ARM build (I have access to AArch64, but not ARM), ARM is the other target to use the have_ptrace_getregset global, but I'd assumed this was x86 only! In v7 all I've done is move the declaration of the have_ptrace_getregset global into the gdb/nat/ directory, I've left the definitions alone. This allows me to reference the global from code I will (later in the series) add to the gdb/nat/ directory, but I don't have to worry about testing the ARM build as the definitions haven't moved. This could be cleaned up _more_ later, moving the definition of have_ptrace_getregset into the gdb/nat/ directory, but I don't plan to do this as part of this series. - No other patches have changed. - Rebased the series onto something closer to HEAD of current master. In v6: - I merged some of the smaller patches which had been approved, and which were only loosely connected to this series, i.e. they were refactoring, or trivial cleanup patches. - I've reordered some of the remaining patches, moving the smaller patches towards the start of the series, these are largely unchanged and have mostly already been reviewed and/or approved. If there's no negative feedback for these smaller patches in this new order then I'll likely merge some more of these smaller ones to try and get the size of this series down. - Patches #1, #2, #3 are pretty much unchaged, and are either already approved or have at least been reviewed. - Patch #4 is new, though this is pretty similar to patch #3, I don't expect any problems from this patch. - Patch #5 has an error restored that Felix pointed out I'd deleted by mistake. The error was, as Felix commented, restored (in a different way) in a later patch anyway, but dropping it in this patch was a mistake. - Patch #6 has already been approved. - Patch #7 has had some changes after feedback from Felix, the x86_linux_tdesc_for_tid function has dropped its callback argument, and we now take two pointers in which the function caches two different pieces of state. I think this is actually a huge improvement, thanks Felix! I've also removed passing have_ptrace_getfpxregs by pointer to this function. Instead, after patch #4, we can now access have_ptrace_getfpxregs as a global, just like we do for have_ptrace_getregset, this is another great improvement I think. I've also fixed a bug in x86_linux_tdesc_for_tid which was present in the original code, if we're NOT on x86-64, and we do have HAVE_PTRACE_GETFPXREGS defined then we will now always call i386_linux_read_description. Previously, we'd only call i386_linux_read_description when have_ptrace_getfpxregs was TRIBOOL_UNKNOWN, which was the first time x86_linux_tdesc_for_tid was called. - Patch #8, I've renamed some of the data structures, and reworded some of the comments, to try and make it clearer that the code added in this commit is all about checking xstate (xcr0) feature bits, and is not claiming to represent all possible state which might ever need to be checked when creating a tdesc. Felix correctly pointed out that the previous naming / commenting was rather misleading, and though I believe the code was (and is) doing the right thing, the comments gave the impression that things had been overlooked. - Patch #9, the core ideas of this patch are unchanged. I've reworked the commit message to try and explain myself better. In v5: - Felix pointed out that building gdbserver with the '-m32' flag on an x86-64 host would fail. This is fixed in V5 with the addition of patch #4. This patch moves the have_ptrace_getfpxregs global into the gdb/nat/ directory and fixes the includes so that the the declaration is seen where needed, - I've rebased onto a slightly later commit. In v4: - I tried merging V3, but it turned out I broke pretty much everything that wasn't x86 based when configured with --enable-targets=all, - The problem was a failure to correctly split the shared code between the gdb/arch/ and gdb/nat/ directories, as a consequence, code which is needed on a non x86 based host to support x86 based targets wasn't available to the compilation, and the build failed, - In V4 I've gone through every patch and resplit the code in a way which I now believe is correct, I've done the following tests: + On a non x86 host I've built GDB to support only the current host as a target, to support all targets, and to support x86-64 and i386 linux targets, + On an i386 virtual machine I built GDB only for the host as a target, and for all targets. I regression tested the all targets build for unix, native-gdbserver, and native-extended-gdbserver, + On an x86-64 machine I've built GDB for only the current host as a target, and for all targets. I regression tested the all targets build for unix, native-gdbserver, and native-extended-gdbserver. - Only patches 6, 8, and 10 require significant review. All of the other patches are pretty trivial (though reviews always welcome). - I think there's more improvements that can be made to the x86 target description creation/lookup/caching. This series only changes the Linux lookup, and we still cache i386/amd64/x32 separately. In the future I think we can merge all x86 target description caching into a single data structure, this would be for all OS variants and all ABI variants. Though making that "grand unification" will certainly require some of the code in this series to change, I think the bulk of it will remain, and trying to do everything in one series is just going to result in an even larger series. I'd prefer to get these first patches merged, then come back to build on this work once this is merged and we know there's no problems with it. In v3: - Rebased. Nasty merge conflict with 4bb20a6244b7091 which I think I've resolved, but am unable to test. Reposting so the author of that other commit can validate. - Initial testing looks good. Full tests are still running. In v2: - Rebase to current upstream/master, no merge conflicts, - Retested. --- Andrew Burgess (9): gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition gdbserver/x86: move no-xml code earlier in x86_linux_read_description gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory gdb: move have_ptrace_getregset declaration into gdb/nat directory gdb/x86: move reading of cs and ds state into gdb/nat directory gdb: move xcr0 == 0 check into i386_linux_core_read_description gdb/gdbserver: share some code relating to target description creation gdbserver: update target description creation for x86/linux gdb/gdbserver: share x86/linux tdesc caching gdb/Makefile.in | 10 +- gdb/amd64-linux-tdep.c | 32 +-- gdb/amd64-linux-tdep.h | 6 - gdb/arch/amd64-linux-tdesc.c | 61 +++++ gdb/arch/amd64-linux-tdesc.h | 30 +++ gdb/arch/i386-linux-tdesc.c | 51 ++++ gdb/arch/i386-linux-tdesc.h | 29 +++ gdb/arch/x86-linux-tdesc-features.c | 267 +++++++++++++++++++++ gdb/arch/x86-linux-tdesc-features.h | 62 +++++ gdb/arch/x86-linux-tdesc.h | 37 +++ gdb/configure.nat | 9 +- gdb/configure.tgt | 11 +- gdb/i386-linux-nat.c | 26 +- gdb/i386-linux-tdep.c | 42 ++-- gdb/i386-linux-tdep.h | 23 -- gdb/linux-nat.c | 2 +- gdb/linux-nat.h | 3 - gdb/{i386-linux-nat.h => nat/i386-linux.c} | 15 +- gdb/nat/i386-linux.h | 37 +++ gdb/nat/linux-nat.h | 3 + gdb/nat/x86-linux-tdesc.c | 129 ++++++++++ gdb/nat/x86-linux-tdesc.h | 54 +++++ gdb/nat/x86-linux.c | 47 ++++ gdb/nat/x86-linux.h | 28 +++ gdb/x86-linux-nat.c | 119 +-------- gdbserver/configure.srv | 12 + gdbserver/i387-fp.cc | 9 +- gdbserver/i387-fp.h | 4 +- gdbserver/linux-amd64-ipa.cc | 46 +--- gdbserver/linux-i386-ipa.cc | 26 +- gdbserver/linux-low.cc | 2 +- gdbserver/linux-low.h | 2 - gdbserver/linux-x86-low.cc | 210 ++++++---------- gdbserver/linux-x86-tdesc.cc | 142 +---------- gdbserver/linux-x86-tdesc.h | 56 ----- gdbsupport/x86-xstate.h | 20 ++ 36 files changed, 1028 insertions(+), 634 deletions(-) create mode 100644 gdb/arch/amd64-linux-tdesc.c create mode 100644 gdb/arch/amd64-linux-tdesc.h create mode 100644 gdb/arch/i386-linux-tdesc.c create mode 100644 gdb/arch/i386-linux-tdesc.h create mode 100644 gdb/arch/x86-linux-tdesc-features.c create mode 100644 gdb/arch/x86-linux-tdesc-features.h create mode 100644 gdb/arch/x86-linux-tdesc.h rename gdb/{i386-linux-nat.h => nat/i386-linux.c} (77%) create mode 100644 gdb/nat/i386-linux.h create mode 100644 gdb/nat/x86-linux-tdesc.c create mode 100644 gdb/nat/x86-linux-tdesc.h delete mode 100644 gdbserver/linux-x86-tdesc.h base-commit: a4f76c0765a0b9c643dc91d5a398a1cd9519572b -- 2.25.4