lkml.org 
[lkml]   [2011]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RFD: x32 ABI system call numbers
    Date
    On Thursday 01 September 2011 18:51:35 H. Peter Anvin wrote:
    > On 09/01/2011 05:49 PM, Pedro Alves wrote:
    > >>>
    > >>> struct iovec
    > >>> {
    > >>> void __user *iov_base; /* BSD uses caddr_t (1003.1g requires
    > >>> void *) */
    > >>> __kernel_size_t iov_len; /* Must be size_t (1003.1g) */
    > >>> } __attribute__((x32_abi_64));
    > >>>
    > >>> typedef long time_t __attribute__((x32_abi_64));
    > >>>
    > >>> The x32_abi_64 attribute converts pointers and longs back to 64-bit and
    > >>> adjusts the alignment accordingly. If we tag all userspace visible
    > >>> structures with this attribute, we can use the 64-bit ABI without changes.
    > >
    > > I would expect no new gcc extension to be needed for that -- there's the
    > > mode attribute (you can read DI as 64-bit):
    > >
    > > typedef void * __kernel_ptr64 __attribute ((mode(DI)));
    > >
    > > struct iovec
    > > {
    > > __kernel_ptr64 iov_base;
    > > ...
    > > };
    > >
    >
    > Does that work for *writing*, too? That might be a very useful little
    > escape hatch for some particularly tight corners.

    I've tried to use that extension in other contexts without much success,
    mostly I believe because gcc back-end support for it needs to be there
    but wasn't at the time I tried. If the x32 back-end does this correctly,
    you win.

    A different gcc extension that might turn out to be useful here is the
    named address space extension that lets you annotate a pointer to
    be different from other pointers. On the SPU architecture we use this
    for the destinction between local 18 bit pointers and 64-bit pointers
    into the user process address space.

    Arnd


    \
     
     \ /
      Last update: 2011-09-02 10:07    [W:3.321 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site