RFC: cross-libkvm/libthread_db/proc_service

Marcel Moolenaar xcllnt at mac.com
Mon Jul 21 22:14:47 UTC 2008


On Jul 21, 2008, at 7:49 AM, 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?

The impact will be bigger, though. Any reference to kvm_read/kvm_write
needs to be changed then. Think about stock GDB and various ports for
example. Are we willing to differentiate from other OSes, provided we
are willing to follow it through all the way?

-- 
Marcel Moolenaar
xcllnt at mac.com





More information about the freebsd-arch mailing list