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 5799438F9807 for ; Thu, 6 Jun 2024 09:16:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5799438F9807 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 5799438F9807 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=1717665378; cv=none; b=Zl0BSaXyrGnn1zfvbdZNiV770Ng8n91P6aS1j6gWZd7Ez/R4OFAcm1TQupbWTFd9Bo9oGL+7Yj8z8/SC4j5rk4HV4LWToKKQ9CHW9xWGsGUnlhXinOj0j9k360KCV1Fh+yNHhm6tVKve5Ji7/j0eq+9AyyKnOQkp8gcUrJUTpLE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717665378; c=relaxed/simple; bh=i/NX1KIWSN3ywejtAQI02EDvKkiWWgwGpQSvDEpYpFY=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=ifr0JAROIkjrJYmpE2dtfr/tzwRxLd5UoLHATWNrDpOpwp20D+9sGmPsO+PWQUqg+ShVDtB5354qtCrzW9XfmexG/BttllE3jSEHf9PJFEivC/IUIXdtBduPV/H4CbXZZGTqwfnKTciFCtHcGFsTnWfM+vPwW739UbjdaOt1RhA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717665376; 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=vQ7b9SjaqYo60nAhD2Jtp2+GTqRDqhUKV0xKPGP6Eb0=; b=JJLVztwbMPPKXNq7nm5z1fjXbkqp1D1oYOdPUXtw/pQIV4qGb5nVeJy9uTM1324i1TfK8X XQJktGRrBfgnZI0y22yy5YkjPjsYVQsXK+AjlLm8zHXTSYuFz9WL5RGJSDTESqUJiSXDQw Of0PjGvnSxfrwqO5EBsQu4mBm8RNz+Q= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-403-H0XFySYWOe6-HQhkFHLyEg-1; Thu, 06 Jun 2024 05:16:14 -0400 X-MC-Unique: H0XFySYWOe6-HQhkFHLyEg-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2ea9429e1deso5549121fa.2 for ; Thu, 06 Jun 2024 02:16:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717665372; x=1718270172; 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=vQ7b9SjaqYo60nAhD2Jtp2+GTqRDqhUKV0xKPGP6Eb0=; b=cdNxytzuiaWvZEXeLEj3AWIq4j6RjXsh+DpqCWxfE5gK6gAhB8nrIfw31eT7U4SprF GjEKRlLeR2yy08KRrbKtd5jjwWRIGFAer8LJ4/6D3xF3UboIwX709+qbFHEfnQnt7d1B JPgeMo19lfepv1faedkawtjI9UBW1szeg3EHqYo1t+78cRAU/Ft2XQSZ6h7Yg+FyVjj1 nUhFwi9RPbXxuT3k4Xc55cLMjO2O4Phd9B8ruGePLcLfnxGP3oXctwUK2T/KMNPPFL7c po77HNqbL9Ct6ttvcqddeVfzOJ9aXAgLCE9w/YHZw1a89SiE8x44plTkcF5xMWF77nfh 41SQ== X-Gm-Message-State: AOJu0YyX0cgpr4XR2yL43aAl+4m5n4+buI/OFbc8KwQO3rHIFJ6WbjEM ANUCD330zSPkyPTIauznlzDoo6aWnS/lOW1fFPuQO9kpGhZg0ARsXHKv7VgCOJ/086/0ZMzux0Z WLvfcmsY9iJY1bItFjUUlxVh3tMSg46asxYnLgNWwQhzpMjtecBU4VBJHz9H3Gb7lA+ZAy2uWk5 jU/vJJRHC4OVkXv5iaiCd3sO2wqq2aOjjDYDcy9wwVWRk= X-Received: by 2002:a2e:be1e:0:b0:2e9:60b8:eb7 with SMTP id 38308e7fff4ca-2eac7a0a371mr35797211fa.29.1717665371546; Thu, 06 Jun 2024 02:16:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGXtw+reAdoHjtcSehPaU0jpOSz5x7U+JJxi9Jshv7cYDWujyl54upRgDQdXGjokRvEEpDOmA== X-Received: by 2002:a2e:be1e:0:b0:2e9:60b8:eb7 with SMTP id 38308e7fff4ca-2eac7a0a371mr35796861fa.29.1717665370800; Thu, 06 Jun 2024 02:16:10 -0700 (PDT) Received: from localhost ([31.111.84.186]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4215c2d7935sm14551495e9.48.2024.06.06.02.16.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jun 2024 02:16:10 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess , felix.willgerodt@intel.com Subject: [PATCHv8 0/9] x86/Linux Target Description Changes Date: Thu, 6 Jun 2024 10:15:56 +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=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: In v8: - Addressed Felix's feedback on patches 7, 8, and 9. Mostly minor stuff, typos, extra comments, though in patch 7 I did drop an error message parameter from x86_linux_tdesc_for_tid, but I still think this is a pretty minor change. - Rebased to current master, no real merge problems. Retested on x86-64 GNU/Linux, with unix, native-gdbserver, and native-extended-gdbserver boards, no regressions found. 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 | 66 +++++ gdb/arch/amd64-linux-tdesc.h | 30 +++ gdb/arch/i386-linux-tdesc.c | 56 +++++ 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 | 133 ++++++++++ gdb/nat/x86-linux-tdesc.h | 50 ++++ gdb/nat/x86-linux.c | 47 ++++ gdb/nat/x86-linux.h | 28 +++ gdb/x86-linux-nat.c | 117 +-------- 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 | 205 +++++----------- gdbserver/linux-x86-tdesc.cc | 142 +---------- gdbserver/linux-x86-tdesc.h | 56 ----- gdbsupport/x86-xstate.h | 20 ++ 36 files changed, 1032 insertions(+), 633 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: 2db414c36b4f030782c2c8a24c916c3033261af0 -- 2.25.4