Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52DDD1AC.3080207@barfooze.de>
Date: Tue, 21 Jan 2014 02:47:24 +0100
From: John Spencer <maillist-musl@...fooze.de>
To:  musl@...ts.openwall.com
Subject: Re: Discussion of partly-invasive changes needed for x32 port

Rich Felker wrote:
> 1. System calls take 64-bit arguments, whereas the existing syscall
> framework in musl (and on the kernel side for all other archs/abis)
> uses long arguments.
> 
> The current internal syscall macros cast all arguments to long; this
> allows accepting either pointers or integer types smaller than long
> without the caller having to make any casts. However this does not
> work for x32, where some syscalls actually need 64-bit arguments (e.g.
> lseek). The following macro, which replaces the long cast on x32,
> solves the problem:
> 
> #define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) (X) : (long long) (X)

when i understood your last mail correctly, it's ok to go forward with a
GNUC enhanced version of this macro that can deal with timespec ?
that would solve 1 + 2.

 > For normal syscalls that go via the inline functions, these inline
 > functions are defined in syscall_arch.h (arch-specific) where it's
 > easy to change them to use long long instead of long for their
 > argument types. However, for cancellable syscalls, they go through
 > __syscall_cp in src/thread/cancel_impl.c. The proposal so far is to
 > expose these internals from the internal syscall.h and syscall_arch.h
 > to cancel_impl.c. I'm not opposed to this, but if we go this way, the
 > type name should be self-documenting (e.g. klong, klong_t,
 > syscall_long_t, or something similar) rather than the current proposal
 > (__sca) that's non-obvious unless you go digging for it. Alernatively,
 > src/internal/syscall.h could pull in register_t from alltypes.h
 > (having internal headers use alltypes.h directly is not something we
 > do yet, but it could be done) and we could simply always use
 > register_t for these arguments.

afaik mips n32 uses long arguments for syscalls, so using register_t 
would not work there.
so it seems our choices are either _Klong in alltypes.h or in a special 
bits header (bits/k_long.h), so we dont have to include syscall_arch.h 
in other bits headers and expose other unrelated internals (point 3).

> 3. A number of other structures in the public headers differ from
> their userspace C type layout on other archs because they're setup to
> match the 64-bit kernel structs. This requires either changing some
> member types to match the 64-bit kernel ones (this is usually a bad
> idea, and sometimes even non-conforming like with tv_nsec) or adding
> adjacent padding members for the unused "high" part of the 64-bit
> value. In many cases, this requires either moving structures from the
> shared headers to bits/*, or coming up with clever ways to avoid doing
> so.

i've seen this in linux/sysinfo.h today:
         __kernel_ulong_t totalhigh;     /* Total high memory size */
         __kernel_ulong_t freehigh;      /* Available high memory size */
         __u32 mem_unit;                 /* Memory unit size in bytes */
         char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)];   /* 
Padding: libc5 uses this.. */

so the padding evaluates to either char _f[0] where __kernel_ulong_t is 
64bit, or _f[8] for 32bit.

seems like a workable solution, which doesn't even require bitfield hacks.
but we need again the kernel_long to work with...
it seems there's no way around it.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.