RFC: cross-libkvm/libthread_db/proc_service

[Alfred Perlstein]

* Daniel Eischen <eischen at vigrid.com> [080721 14:11] wrote:
> 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"?

Isn't it a bit strange to export 64bit pointers to 32 bit userspace?

Once this "hurdle" is breached, everything else will be horked as
well, all pointers to internal structures will be hosed as well
and need magic to read them.

It seems like a real uphill battle to pound 64bit pegs into
32bit holes.

I would like to see the "next steps" as in, what is expected to work
after this is added and what will need additional shoe-horning to
work.

It seems to make a lot more sense to allow for 32bit compat sysctls
than this.

-- 
- Alfred Perlstein