RFC: cross-libkvm/libthread_db/proc_service

[Marcel Moolenaar]

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 at mac.com