Date: Mon, 21 Jul 2008 17:00:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@freebsd.org> Cc: Marcel Moolenaar <xcllnt@mac.com>, freebsd-arch@freebsd.org Subject: Re: RFC: cross-libkvm/libthread_db/proc_service Message-ID: <Pine.GSO.4.64.0807211659450.2608@sea.ntplx.net> In-Reply-To: <200807211049.47579.jhb@freebsd.org> References: <34889018-8358-46AC-897E-32767FB84E14@mac.com> <200807211049.47579.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Jul 2008, John Baldwin wrote: > On Saturday 19 July 2008 01:59:29 pm Marcel Moolenaar wrote: >> All, >> >> We have a couple of interfaces/APIs that can't be used cross-platform. >> >> 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. >> >> 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>. >> >> 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. >> >> 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(). >> >> 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. >> >> Comments/thoughts? > > I think this is ok. However, can't you just make newer (1.1) versions of > kvm_read/write instead of adding a new API? You mean, "how about symbol versioning it"? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0807211659450.2608>