[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
