Date: Sat, 19 Jul 2008 21:37:25 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: cross-libkvm/libthread_db/proc_service Message-ID: <20080719183725.GM17123@deviant.kiev.zoral.com.ua> In-Reply-To: <34889018-8358-46AC-897E-32767FB84E14@mac.com> References: <34889018-8358-46AC-897E-32767FB84E14@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080719183725.GM17123>