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 4681C385840C for ; Fri, 23 Feb 2024 00:25:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4681C385840C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4681C385840C Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=96.47.72.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708647951; cv=pass; b=SLkmm0bQnqwEFZ+jqEcPf1+ViNsTLKZRLcw+CTr97kU9cY47ZNaucX/nPboaUjA8BR16WHua4oM7WUAcubuRbr+s7/pFPmsJd11d/RsS/2AcSm0XATusd766+ai4pzGXcytEHfEHg6NfTuMzdF6wPFxoGWTejEdnjwtAzx50Xmc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708647951; c=relaxed/simple; bh=wO68BwU/hm3llV9aZ8Y3/goaBv5CvkxSadoznbnJF+g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=YiVoD+2CXjeALTlZjIMaEbrXfxEodi0bP6vdOba5vMmE6fNLHjpxeGaM1fHpfWAoKwuJM/i7K+sTJQ+Rj5i/axJZWPOHJnzgR0xMwnRt/JaRh0/0yNX++09lpQNq3/2t29J/XJe5BBQd7tZAkAce8eK3GxvmY2trfGPScHWVVG0= ARC-Authentication-Results: i=2; server2.sourceware.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 4TgrQL1Sq0z3wWD; Fri, 23 Feb 2024 00:25:46 +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 4TgrQL0dsTz4NSB; Fri, 23 Feb 2024 00:25:46 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708647946; 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=o9eW0ehOV+v5VlyKMJPaEnw5OtV2gMORHdfp/kDBHRw=; b=Gz+Xw4mlcR6ezJyybdh1Bk7DBiDzOPooea+LaQOyvCzndAuIFTCZOsjC6whGUWGPQhYfSz pXyV/E+52fTHd23BrGYr1h8aFypJlc5fzc6NmuEAP8VU9SxYQ8phHzVbRe5IHqEW9ynYD+ XyZquP8cqh7hWwEru04KH0W9nWfAZaegzSP5j0b0qVgemT+7eg3WhWGQS+gvuDywzjyWSR DfEC15ENN4FJ8xo5QSPtB8YO9Pv8M25NjsaaffdcnliGecBCquOL7ETm9eXIE1ZN1ndhLq vrYz5pPy3HEu0maEKPg6h0Gbj+mxxxFIlYjXv6a8tr7JQVJ7LCcM+Q8luI6apw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708647946; 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=o9eW0ehOV+v5VlyKMJPaEnw5OtV2gMORHdfp/kDBHRw=; b=VEUEfIvm5EjTPuAbs8jjfji+EVRNFdC4UrMsLojakZK6c6hlMvKhZSpTz+TB1L2KkmP7Kh 8YT0I1hfGuJzG3FqK9RqlFt2YjE356UOIE04GzuPyZu5Jrm9TjxzAJu7ibYG12ATX9nYyC cm7f05JpFoKfmksYD4gwAb0yYGG/1vcldhV7tad3fVWGgnHE9cbekSar/fHobY5vl7dObB AgPsKHKG4HqiObqlZSoGi45ngfU+ZTRMcXDzfJjU6utKcVBLqf6javNpi1VVIpuHE0qwE4 m5NcxHv5h/xHhAbSX9UcYlRTcD5jo9glzoc2HaMBDkwFfVJ2LT3G7q6stZFx/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708647946; a=rsa-sha256; cv=none; b=XDZv2oQQy81veWdFn7z1IbN0pK57FEd682QwMHDphsLxFxPrxxHIEe3R61VkQMBM8g7a11 1upnd3RQAbgW4pKH/Fk8DPiF4kKej2wXVPRCiAGK08gIqN13XUF2Qk/xe3M050bn5VoqU+ e7FuZK1n5taGpbkfjSzHx3oDsA1CfX5U7zB3Rt5hyuvsf7PQw4qHa9GjJth/61c2rvsIhW i/o81aAiy/PNGe7ADMFahGIFq0a4sq0nvMzk9DaIajRQhyPZq/IcnUcdRDfQrMg49Y7ISd 2aWJ8/vh65JSse2pAc7UfRESIzId5Xj8LIEUnaYvmZyEnRYRIMnBt4AyEUqRlg== Received: from [IPV6:2601:644:937f:4c50:9110:97a:5df4:795c] (unknown [IPv6:2601:644:937f:4c50:9110:97a:5df4:795c]) (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 4TgrQK3FCrzR3x; Fri, 23 Feb 2024 00:25:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <5bba5e9a-2834-4cd1-9618-0c8805cfc692@FreeBSD.org> Date: Thu, 22 Feb 2024 16:25:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Port GDB to Hurd x86_64. Content-Language: en-US To: Flavio Cruz , bug-hurd@gnu.org, gdb-patches@sourceware.org Cc: samuel.thibault@gnu.org, simark@simark.ca References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 2/12/24 8:31 PM, Flavio Cruz wrote: > This port extends the existing i686 port to support x86_64 by trying to > reuse existing code whenever it makes sense. > > * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and > position of amd64 registers in the different Hurd structs, including > i386_thread_state. The signal code is very similar to i686, except the > trampoline code is adapted. > * gdb/amd64-gnu-tdep.h: export register offsets for x86-gnu-nat.c. > * gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.h > and adapt it for x86_64. > * gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn > and reuse it for x86_64. > * gdb/configure.host: recognize gnu64 as a host. > * gdb/configure.nat: recognize gnu64 host and update existing i386gnu to > reuse the new shared files. > * gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use > amd64-gnu-tdep.c. > * gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is > copied from i386-gnu-nat.c. This makes it similar to amd64. > * gdb/i386-gnu-tdep.h: export register offsets and number of registers. > * gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this for > i386 and amd64. Updated REG_ADDR to use one of the structures. Added > VALID_REGISTER to make sure it's a register we can provide at this time > (not all of them are available in amd64). FLAGS_REGISTER is either rfl > or efl depending on the arch. Renamed functions and class from i386 to x86 > whenever they can be reused. > > Tested on Hurd x86_64 and i686. > --- > > For Hurd x86_64 to work, "[PATCH] Hurd port: update interface to match > upstream and fix warnings" needs to be applied too. > > gdb/amd64-gnu-tdep.c | 256 ++++++++++++++++++ > gdb/amd64-gnu-tdep.h | 29 ++ > .../i386/{nm-i386gnu.h => nm-x86-gnu.h} | 7 + > gdb/config/i386/{i386gnu.mn => x86-gnu.mn} | 0 > gdb/configure.host | 1 + > gdb/configure.nat | 27 +- > gdb/configure.tgt | 4 + > gdb/i386-gnu-tdep.c | 37 ++- > gdb/i386-gnu-tdep.h | 29 ++ > gdb/{i386-gnu-nat.c => x86-gnu-nat.c} | 128 +++++---- > 10 files changed, 457 insertions(+), 61 deletions(-) > create mode 100644 gdb/amd64-gnu-tdep.c > create mode 100644 gdb/amd64-gnu-tdep.h > rename gdb/config/i386/{nm-i386gnu.h => nm-x86-gnu.h} (83%) > rename gdb/config/i386/{i386gnu.mn => x86-gnu.mn} (100%) > create mode 100644 gdb/i386-gnu-tdep.h > rename gdb/{i386-gnu-nat.c => x86-gnu-nat.c} (75%) > > diff --git a/gdb/amd64-gnu-tdep.c b/gdb/amd64-gnu-tdep.c > new file mode 100644 > index 00000000000..57aeccea8b9 > --- /dev/null > +++ b/gdb/amd64-gnu-tdep.c > @@ -0,0 +1,256 @@ > +/* Mapping between the general-purpose registers in `struct > + sigcontext' format (starting at sc_i386_thread_state) > + and GDB's register cache layout. */ > + > +/* From . */ > +static int amd64_gnu_sc_reg_offset[] = > +{ > + 15 * 8, /* %rax */ > + 12 * 8, /* %rbx */ > + 14 * 8, /* %rcx */ > + 13 * 8, /* %rdx */ > + 10 * 8, /* %rsi */ > + 9 * 8, /* %rdi */ > + 10 * 8, /* %rbp */ > + 11 * 8, /* %rsp */ > + 0 * 8, /* %r8 ... */ > + 8 * 8, > + 7 * 8, > + 6 * 8, > + 3 * 8, > + 2 * 8, > + 1 * 8, > + 0 * 8, /* ... %r15 */ > + 16 * 8, /* %rip */ > + 18 * 8, /* %eflags */ > + 17 * 8, /* %cs */ > +}; > + > +/* From . */ > +static int amd64_gnu_gregset_reg_offset[] = > +{ > + 10 * 8, /* %rax */ > + 5 * 8, /* %rbx */ > + 11 * 8, /* %rcx */ > + 12 * 8, /* %rdx */ > + 13 * 8, /* %rsi */ > + 14 * 8, /* %rdi */ > + 4 * 8, /* %rbp */ > + 19 * 8, /* %rsp */ > + 9 * 8, /* %r8 ... */ > + 8 * 8, > + 7 * 8, > + 6 * 8, > + 3 * 8, > + 2 * 8, > + 1 * 8, > + 0 * 8, /* ... %r15 */ > + 16 * 8, /* %rip */ > + 18 * 8, /* %eflags */ > + 17 * 8, /* %cs */ > + -1, /* %ss */ > + -1, /* %ds */ > + -1, /* %es */ > + -1, /* %fs */ > + -1, /* %gs */ > +}; > + > +/* Offset to the thread_state_t location where REG is stored. */ > +#define REG_OFFSET(reg) offsetof (struct i386_thread_state, reg) You can't use a reference to this OS-specific type in a tdep.c file, only in a nat.c file. tdep.c should be buildable on other platforms to permit cross debugging of core dumps, remote targets, etc. > +/* At REG_OFFSET[N] is the offset to the thread_state_t location where > + the GDB register N is stored. */ > +int amd64_gnu_thread_state_reg_offset[] = > +{ > + REG_OFFSET (rax), /* %rax */ > + REG_OFFSET (rbx), /* %rbx */ > + REG_OFFSET (rcx), /* %rcx */ > + REG_OFFSET (rdx), /* %rdx */ > + REG_OFFSET (rsi), /* %rsi */ > + REG_OFFSET (rdi), /* %rdi */ > + REG_OFFSET (rbp), /* %rbp */ > + REG_OFFSET (ursp), /* %rsp */ > + REG_OFFSET (r8), /* %r8 ... */ > + REG_OFFSET (r9), > + REG_OFFSET (r10), > + REG_OFFSET (r11), > + REG_OFFSET (r12), > + REG_OFFSET (r13), > + REG_OFFSET (r14), > + REG_OFFSET (r15), /* ... %r15 */ > + REG_OFFSET (rip), /* %rip */ > + REG_OFFSET (rfl), /* %rflags */ > + REG_OFFSET (cs) /* %cs */ > +}; > + > +const int amd64_gnu_thread_state_num_regs = > + ARRAY_SIZE (amd64_gnu_thread_state_reg_offset); That said, I also don't see any references to amd64_gnu_thread_state_* in this file, and it looks to only be used in x86-gnu-nat.c, so I think you should instead move this array to x86-gnu-nat.c instead (and similarly for i386_gnu_thread_state_* you added in i386-gnu-tdep.c). -- John Baldwin