Date: Sat, 19 Jul 2008 11:42:44 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: cross-libkvm/libthread_db/proc_service Message-ID: <6EA6C2B0-EF45-4A65-A455-65700BA6B024@mac.com> In-Reply-To: <20080719183725.GM17123@deviant.kiev.zoral.com.ua> References: <34889018-8358-46AC-897E-32767FB84E14@mac.com> <20080719183725.GM17123@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 19, 2008, at 11:37 AM, Kostik Belousov wrote: > On Sat, Jul 19, 2008 at 10:59:29AM -0700, 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 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 ? The impact on the kernel is exactly nil. psaddr_t is not used by the kernel or its interfaces. It's only used for debug related functionality. FYI, -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6EA6C2B0-EF45-4A65-A455-65700BA6B024>