RFC: cross-libkvm/libthread_db/proc_service

[Marcel Moolenaar]

On Jul 22, 2008, at 10:27 AM, Bruce Evans wrote:

> On Wed, 23 Jul 2008, Bruce Evans wrote:
>
>> On Mon, 21 Jul 2008, Alfred Perlstein wrote:
>>
>>> Isn't it a bit strange to export 64bit pointers to 32 bit userspace?
>>
>> Only for pointers in kernel objects, and I think the proposed change
>> doesn't touch that.
>>
>> kvm_read() doesn't use pointers for kernel addresses.  It uses  
>> unsigned
>> longs.  But even uintmax_t is not enough in general, since the  
>> application
>> uintmax_t might be too small to represent a kernel pointer.  The type
>> used shouldn't be fixed-width, but typedefed in an MD way like  
>> vm_offset_t.
>> vm_offset_t gives the correct integral type to use for (mapped)  
>> kernel
>> addresses and related compat_fewer_bit[s] type[s] are needed in  
>> userland.
>> It would probably be too hard to support the general case which  
>> requires
>> the compat types to be arrays or structs.
>
> Bah, I forgot the original mail which already says to use an integral
> type named psaddr_t, and that, unfortunately, this seems to need being
> 64 bits even on pure 32-bit systems in case you want to run an (not
> quite pure) 32-bit application in compat32 mode on 64-bit system  
> without
> recompiling.

Actually, the intend is more generic (or more limited, depending
on how you look at it): the ability to cross-debug any (say ia64)
kernel on any other (say powerpc) machine. The integral needs to
be constant and equal in width across all platforms.  This means
that an uint<#>_t is the best option. The largest we support is
64-bit.

We can already build a cross gdb from the source tree, but without
threading support (libthread_db and proc_service limitation).  We
can't build a cross kgdb from the source tree because of libkvm.
Both I'd like to be able to do.

FYI,

-- 
Marcel Moolenaar
xcllnt at mac.com