From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6Gh1AjnHhWauWxoAWB0awg (envelope-from ) for ; Wed, 03 Jul 2024 17:48:41 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=gER+2lTg; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 064B21E0C3; Wed, 3 Jul 2024 17:48:41 -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 E70811E030 for ; Wed, 3 Jul 2024 17:48:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 62D19385C6CD for ; Wed, 3 Jul 2024 21:48:37 +0000 (GMT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id BC765385840E for ; Wed, 3 Jul 2024 21:48:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC765385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BC765385840E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720043300; cv=none; b=o6SsLw/nKIYaFUtNXUyjwLQfVTmc9cfVYQlGNxou1cgoQnPXuD3ub2a4oGUbLMynXvsehD3AUE6i36oSJ0jFSnFdFXRrwTg4cmtcwBdnP7VptSWws570Q0LkSm/xlNTrYaE4eFYY3YpnjSSri1X+rNVgf33gye44FWa4zFFXie0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720043300; c=relaxed/simple; bh=pomK+AwSxpf500aF2wrFF0h/ESylIB7VfrQOMobfvRE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=xUsv6yppmgshqijKinxOQC5PpbJch8BLjCVNq4QwM81XTQF8rX2I0tf4gZa5w/CKHJ8fSHMPg82SxQFn28R7anCXCbdabbXIwju9dAoiqeZErBchivZ66L0uTuTCQnnhYhv2HvxmxMsznJWONPlDvpyo/wds2XKlTRRDNewyZAc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-df4d5d0b8d0so5573408276.2 for ; Wed, 03 Jul 2024 14:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720043297; x=1720648097; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hebPTSxSk6CjzbWMuUDXoN1AN1n+TSCfmnsnKGG90/E=; b=gER+2lTgovhBF4B4INtW9E023aGlqSdMLyQxvrAZBGeHMSRo9l7iTm6irJDN0S8FEl WYQg6nEn7ZDGq+qqHIGeBOnwkq+IpjbiyeSKFc7sEHmc3+raFKW4DnhyTVQGZBAoHDeW 36Vlm/LPVk3yNZ3/XlMI6InWpE2FxYndzEdVw3ik9nomCQ0LZcACQGEsuAvWFwxIbzYV EF/L4Z8zhLbIOJ3BV/QnqWZ+zOWfKfS/MFXr95IYfZ9tILqqPQSJcma/9wkLoI5NPvne U/B82uvp+WtXhFTjwEhxTxEkpdX0mn5VU8oAhrUBTgHoTRZRCvYkjY1BUpIDfs6RBUI5 uUBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720043297; x=1720648097; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hebPTSxSk6CjzbWMuUDXoN1AN1n+TSCfmnsnKGG90/E=; b=P20gQj1q+2q4HmFiAMMWORygH7B3sNMNrx6EdCDfKOv3hb4sgXAazkAQch8P/cncHs zHYDKsGEbYsS0xIZWP+eBW7O70ZDOr3K7+dz3StraxikJCI4yMvN1/Wsw+fM8zuj+41W Y9Xh1ujHLAg+sLjEo3/ilh64dSQtmCTbe/DFz7xlFxMW91z1ANClUQJymhdpgBdagGi9 1ZvUCdOVlXAf3P19UFJ7BhunznTQS4vMY5LfJuk3SFfn1248uyQxz2wZRxgJdDzHGqSk ecNqefWF3qGS/HWFA1SRUl8oKBDOhF2IizJkVypUH8ShpHO3qUhz0LXugcrJofjUa52e 3wlw== X-Gm-Message-State: AOJu0YycXd9CXGyUaaEWyRbvp1Cq2g/OSfHOLfvIFL9Spfb9iY0WndW0 Rrie3rF0/0bwJlC5SwNgop7XvBEh8Gf9a+2PJmpqlef4rN7QVWyqlr2g/pdChxEYGRllOwvJu3t 39wS2n7+dzB+nRzJTu2ap07nLYQ== X-Google-Smtp-Source: AGHT+IH8Vy8yp+yrpls+INIgyFhwhFC1TIcDIxZbVFTMY4Je46eiAyHyGziSpP3IRSAhzCgXtEZ3XPiNMkecV5/pTrw= X-Received: by 2002:a25:26ce:0:b0:dff:3634:4d75 with SMTP id 3f1490d57ef6-e036ec6d978mr13245890276.61.1720043296932; Wed, 03 Jul 2024 14:48:16 -0700 (PDT) MIME-Version: 1.0 References: <5bba5e9a-2834-4cd1-9618-0c8805cfc692@FreeBSD.org> <20240224052832.3051313-1-flaviocruz@gmail.com> In-Reply-To: From: =?UTF-8?B?RmzDoXZpbyBDcnV6?= Date: Wed, 3 Jul 2024 22:48:05 +0100 Message-ID: Subject: Re: [PATCH v2] Port GDB to Hurd x86_64. To: John Baldwin Cc: gdb-patches@sourceware.org, bug-hurd@gnu.org, samuel.thibault@gnu.org, simark@simark.ca Content-Type: multipart/alternative; boundary="000000000000b6506e061c5ec971" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 --000000000000b6506e061c5ec971 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2024 at 11:15=E2=80=AFPM John Baldwin wro= te: > On 2/23/24 9:28 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. > > The signal code is very similar to i686, except the trampoline code > > is adapted. > > * 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 t= o > > 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-nat.c: rename it to x86-gnu-nat.c since we reuse this fo= r > > 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 r= fl > > 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. > > --- > > > > I addressed John's comments and moved amd64_gnu_thread_state_* and > > i386_gnu_thread_state_* to x86-gnu-nat.c. The new patch also contains a > few > > changes that makes backtracing through shared libraries work. > > Thanks, this generally looks ok to me. > > One question I have is if you need nat/x86-xstate.o for the native Hurd > x86_64 > target? The i686 target doesn't use it and I didn't see any references i= n > the patches to XSAVE support, so I suspect you don't need it. Were you > getting > a link error without it, or is it something you copied from Linux x86_64? > If > the latter, it is probably best to drop it for now until you add XSAVE > support > in the future (which would presumably apply to both i686 and x86_64). > You are right, nat/x86-xstate it's not needed yet. I mailed a second version of this patch without requiring nat/x86-xstate.o plus some updates to make sure the code still compiles with the newest changes in GDB. Thank you > > Reviewed-By: John Baldwin > > -- > John Baldwin > > --000000000000b6506e061c5ec971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 27, 2024 at 11:15=E2=80= =AFPM John Baldwin <jhb@freebsd.org> wrote:
On= 2/23/24 9:28 PM, Flavio Cruz wrote:
> This port extends the existing i686 port to support x86_64 by trying t= o
> reuse existing code whenever it makes sense.
>
> * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
>=C2=A0 =C2=A0 position of amd64 registers in the different Hurd structs= .
>=C2=A0 =C2=A0 The signal code is very similar to i686, except the tramp= oline code
>=C2=A0 =C2=A0 is adapted.
> * gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.= h
>=C2=A0 =C2=A0 and adapt it for x86_64.
> * gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn
>=C2=A0 =C2=A0 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
>=C2=A0 =C2=A0 reuse the new shared files.
> * gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use
>=C2=A0 =C2=A0 amd64-gnu-tdep.c.
> * gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is<= br> >=C2=A0 =C2=A0 copied from i386-gnu-nat.c. This makes it similar to amd6= 4.
> * gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this f= or
>=C2=A0 =C2=A0 i386 and amd64. Updated REG_ADDR to use one of the struct= ures. Added
>=C2=A0 =C2=A0 VALID_REGISTER to make sure it's a register we can pr= ovide at this time
>=C2=A0 =C2=A0 (not all of them are available in amd64). FLAGS_REGISTER = is either rfl
>=C2=A0 =C2=A0 or efl depending on the arch. Renamed functions and class= from i386 to x86
>=C2=A0 =C2=A0 whenever they can be reused.
>
> Tested on Hurd x86_64 and i686.
> ---
>
> I addressed John's comments and moved amd64_gnu_thread_state_* and=
> i386_gnu_thread_state_* to x86-gnu-nat.c. The new patch also contains = a few
> changes that makes backtracing through shared libraries work.

Thanks, this generally looks ok to me.

One question I have is if you need nat/x86-xstate.o for the native Hurd x86= _64
target?=C2=A0 The i686 target doesn't use it and I didn't see any r= eferences in
the patches to XSAVE support, so I suspect you don't need it.=C2=A0 Wer= e you getting
a link error without it, or is it something you copied from Linux x86_64?= =C2=A0 If
the latter, it is probably best to drop it for now until you add XSAVE supp= ort
in the future (which would presumably apply to both i686 and x86_64).

You are right, nat/x86-xstate it's not n= eeded yet. I mailed a second version of this
patch without requir= ing nat/x86-xstate.o plus some updates to make sure the code
stil= l compiles with the newest changes in GDB.

Thank y= ou
=C2=A0

Reviewed-By: John Baldwin <jhb@FreeBSD.org>

--
John Baldwin

--000000000000b6506e061c5ec971--