From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Discussion of partly-invasive changes needed for x32 port
Date: Mon, 20 Jan 2014 21:18:38 -0500 [thread overview]
Message-ID: <20140121021838.GI24286@brightrain.aerifal.cx> (raw)
In-Reply-To: <52DDD1AC.3080207@barfooze.de>
On Tue, Jan 21, 2014 at 02:47:24AM +0100, John Spencer wrote:
> 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.
I think so. Keep in mind the timespec one needs to apply only to const
timespec pointers (non-const ones are results where the kernel needs
to write the result into the caller's structure). I think we should
also use Jens' idea to avoid multiple-evaluation of the argument. And
the result should be cast to unsigned long, so that the final result
of the __scc macro always has integer type.
> > 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.
There's no reason __syscall_cp has to use the same calling convention
as the kernel, as long as the argument type is sufficiently wide to
convey all possible arguments. So register_t would work even when it's
64-bit and the kernel uses 32-bit. However I tend to think using the
right type is probably cleaner since getting register_t requires at
least one hack anyway.
> 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).
Well this possibility is unrelated to items 1/2, so I think you're
getting ahead of yourself. In any case, bits/k_long.h would not be the
right place (bits/* are _never_ included directly and don't have
multiple-include guards; they're included only from the associated
public header they go with).
> >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.
This is a rather ugly legacy interface that's really the least of our
concerns. And the x32 modification of it breaks the documented API
(where the members are longs); for example, correct programs may be
passing them to printf with %lu... As usual, the kernel/glibc folks
did not think before they did this stuff...
Rich
next prev parent reply other threads:[~2014-01-21 2:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 7:41 Rich Felker
2014-01-20 8:43 ` Luca Barbato
2014-01-20 9:25 ` Jens Gustedt
2014-01-20 10:12 ` John Spencer
2014-01-20 10:55 ` Jens Gustedt
2014-01-20 23:57 ` Rich Felker
2014-01-21 8:29 ` Jens Gustedt
2014-01-21 11:33 ` Szabolcs Nagy
2014-01-21 13:59 ` Jens Gustedt
2014-01-21 1:47 ` John Spencer
2014-01-21 2:18 ` Rich Felker [this message]
2014-02-02 6:50 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140121021838.GI24286@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).