mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Possible patch for __syscall_cp
Date: Tue, 20 Feb 2018 21:03:57 -0500	[thread overview]
Message-ID: <20180221020357.GA1436@brightrain.aerifal.cx> (raw)
In-Reply-To: <DB6PR0502MB3016B1C17087556CB33BDC5AE7F50@DB6PR0502MB3016.eurprd05.prod.outlook.com>

On Wed, Feb 14, 2018 at 12:09:18PM +0000, Nicholas Wilson wrote:
> On 13 February 2018 14:49, Szabolcs Nagy wrote:
> > i think your patch is ok (__syscall6 should behave the same
> > way as __syscall other than the inlining), but you can fix
> > it for your target only by adding
> >
> > static inline long __syscall(long n, long a, long b, long c, long d, long e, long f)
> > {
> >        return __syscall6(n,a,b,c,d,e,f);
> > }
> >
> > to syscall_arch.h
> 
> Yes, that's the approach I was thinking of when I mentioned we could
> just implement __syscall. In fact, _syscall is declared as varargs,
> so it would have to be:
> 
> static inline long __syscall(long n, ...)
> {
>   va_list va;
>   va_start(va, n);
>   long a = va_arg(va, long);
>   ... etc
>   long f = va_arg(va, long);
>   return __syscall6(n, a, b, ..., f);
> }
> 
> The question really is - would you prefer archs to define __syscall
> that way, or would you rather patch __syscall_cp to allow macro
> expansion? In your opinion, which is cleaner? If you don't want to
> see a shim like that in the archs, would you consider applying the
> __syscall_cp patch for us?

The macro suppression is intentional so that the stub version of
__syscall_cp (only used in static linking without thread cancellation
linked) is just a tail call to __syscall rather than a bunch of
register shuffling. Being that the whole point of the stub version is
to avoid the size cost of cancellation logic in small static linked
programs, it doesn't make sense to make a change here.

musl ports should define an external (but hidden) function __syscall
replacing (the empty) src/internal/syscall.c. Perhaps that file should
actually be non-empty and look like the above, which would work
(albeit suboptimally) for any arch that doesn't make an external call
for __syscall6.

Unfortunately there are some messy questions about how many arguments
__syscall is called with and whether it's actually valid for it to be
defined with a C function using va_arg rather than in asm. These are
independent of whether we apply your patch or not, I think, and they
should probably be fixed by ensuring that any place where the external
__syscall is called actually passes 6 arguments, by adding dummy zero
arguments to the __syscallN macros in the SYSCALL_NO_INLINE case, and
in the syscall_arch.h files that use it.

This is all much messier than it should be...

Rich


  reply	other threads:[~2018-02-21  2:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13 14:28 Nicholas Wilson
2018-02-13 14:49 ` Szabolcs Nagy
2018-02-14 12:09   ` Nicholas Wilson
2018-02-21  2:03     ` Rich Felker [this message]
2018-02-21 10:47       ` Nicholas Wilson

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=20180221020357.GA1436@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).