RFC: cross-libkvm/libthread_db/proc_service - FreeBSD

This is a discussion on RFC: cross-libkvm/libthread_db/proc_service - FreeBSD ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: RFC: cross-libkvm/libthread_db/proc_service

  1. RFC: cross-libkvm/libthread_db/proc_service

    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 .

    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?

    --
    Marcel Moolenaar
    xcllnt@mac.com



    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  2. Re: RFC: cross-libkvm/libthread_db/proc_service

    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 .
    >
    > 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 ?

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (FreeBSD)

    iEYEARECAAYFAkiCNGUACgkQC3+MBN1Mb4iFuACgmYvOYT3zq4 V8tg99FT3pGeE6
    XwgAoK58mDcyDTBJa+aPVIjXN6wVdN+q
    =1ELf
    -----END PGP SIGNATURE-----


  3. Re: RFC: cross-libkvm/libthread_db/proc_service


    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 .
    >>
    >> 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



    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  4. Re: RFC: cross-libkvm/libthread_db/proc_service

    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 .
    >
    > 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?

    --
    John Baldwin
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  5. Re: RFC: cross-libkvm/libthread_db/proc_service

    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 .
    >>
    >> 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"?

    --
    DE
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  6. Re: RFC: cross-libkvm/libthread_db/proc_service


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



    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  7. Re: RFC: cross-libkvm/libthread_db/proc_service

    * Daniel Eischen [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 .
    > >>
    > >>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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  8. Re: RFC: cross-libkvm/libthread_db/proc_service

    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.

    Bruce
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  9. Re: RFC: cross-libkvm/libthread_db/proc_service

    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. If psaddr_t is 32-bits on i386 but 64-bits on amd64, then
    pure 32-bit i386 applications won't run in compat32 mode on amd64, though
    (not quite pure) 32-bit applications compiled on amd64 will. I don't like
    putting 64-bit knowledge in 32-bit applications but I often compile on
    i386 and run on amd64.

    Bruce
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  10. Re: RFC: cross-libkvm/libthread_db/proc_service


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



    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


+ Reply to Thread