From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 18:48:13 2008 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A83BC1065679 for <arch@freebsd.org>; Sat, 19 Jul 2008 18:48:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 28E3A8FC16 for <arch@freebsd.org>; Sat, 19 Jul 2008 18:48:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6JIbPm4015401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 21:37:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6JIbPKU040733; Sat, 19 Jul 2008 21:37:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6JIbPeE040732; Sat, 19 Jul 2008 21:37:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Jul 2008 21:37:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Message-ID: <20080719183725.GM17123@deviant.kiev.zoral.com.ua> References: <34889018-8358-46AC-897E-32767FB84E14@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Et2Bf2pEd/Zt/VCU" Content-Disposition: inline In-Reply-To: <34889018-8358-46AC-897E-32767FB84E14@mac.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: cross-libkvm/libthread_db/proc_service X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch> List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 19 Jul 2008 18:48:13 -0000 --Et2Bf2pEd/Zt/VCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 19, 2008 at 10:59:29AM -0700, Marcel Moolenaar wrote: > All, >=20 > We have a couple of interfaces/APIs that can't be used cross-platform. >=20 > Take for example libkvm. On a 32-bit platform, we can't typically use > libkvm on a 64-kernel, because the libkvm interface uses u_long for > the target address, which on 32-bit platforms is 32 bits wide. >=20 > Likewise, libthread_db and proc_service are designed for native use > only and need API tweaks to work in a cross-environment. Both use > psaddr_t to represent a target address, which is defined as a void* > in <sys/procfs.h>. >=20 > I'd like to change those interfaces/APIs to allow them to be used in > a cross-platform debugging environment. Basically, this means that a > target address will have to be defined as a uint64_t. Other datatypes > may also need to be retyped. >=20 > For libkvm in particular I don't want to redefine struct kinfo_proc, > struct nlist, etc. While it could be useful in a hybrid 32/64-bit > environment, the effect of such changes have too high a chance to > trickle down various other components/interfaces. Thus, for libkvm > the focus is on kvm_read() and kvm_write(). >=20 > Suggested plan of attack: > o add kvm_xread() and kvm_xwrite() to the libkvm API to minimize > the overall impact. The new functions operate on a 64-bit target > address (psaddr_t). > o change psaddr_t from a void* to a 64-bit integral (sys/procfs.h) > This affects proc_service and libthread_db. And consequently our > threading support in GDB. >=20 > Comments/thoughts? I do not object to the idea, but thing to consider is the backward compatibility. In other words, how much harder would it be to run, e.g., an RELENG_7 jail on the current kernel after the change ? --Et2Bf2pEd/Zt/VCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiCNGUACgkQC3+MBN1Mb4iFuACgmYvOYT3zq4V8tg99FT3pGeE6 XwgAoK58mDcyDTBJa+aPVIjXN6wVdN+q =1ELf -----END PGP SIGNATURE----- --Et2Bf2pEd/Zt/VCU--