klibc - Jul 2020 - [PATCH] Add syscall wrappers required by libkeyutils

On Mon, 2020-07-27 at 05:46 -0700, hpa at zytor.com
wrote:
> On July 27, 2020 2:43:36 AM PDT, Christian Eggers <ceggers at
arri.de> wrote:
> > On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote:
> > > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote:
> > > > ...
> > > > libkeyutils usually invokes syscall() directly. As syscall()
is not
> > > > provided by klibc, libkeyutils has to be slightly modified
for using the
> > > > klibc wrappers.
> > > 
> > > Wouldn't it be more useful for klibc to implement syscall()
then?
> > 
> > I hope that somebody else could respond to this question as I am
likely not
> > skilled enough to answer this.
[...]
> syscall(3) is not implemented by design, because it is silently
> broken on many architectures (mainly 32-bit ones.)
I understand that it's not portable in general, as there are many
architecture-specific quirks in the system call ABI.  But where there
are other established libraries using it, I assume they're already
dealing with those quirks.  Also, the newer system calls that are
likely to be called this way are less quirky, aren't they?

I think that if we can *cheaply* implement a glibc API that allows more
software to build and run on klibc with fewer changes, then we should.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                       - Robert Coveyou


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20200728/89607ba8/attachment.sig>

On July 27, 2020 6:36:27 PM PDT, Ben Hutchings <ben at decadent.org.uk>
wrote:
>On Mon, 2020-07-27 at 05:46 -0700, hpa at zytor.com wrote:
>> On July 27, 2020 2:43:36 AM PDT, Christian Eggers <ceggers at
arri.de>
>wrote:
>> > On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote:
>> > > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote:
>> > > > ...
>> > > > libkeyutils usually invokes syscall() directly. As
syscall() is
>not
>> > > > provided by klibc, libkeyutils has to be slightly
modified for
>using the
>> > > > klibc wrappers.
>> > > 
>> > > Wouldn't it be more useful for klibc to implement
syscall() then?
>> > 
>> > I hope that somebody else could respond to this question as I am
>likely not
>> > skilled enough to answer this.
>[...]
>> syscall(3) is not implemented by design, because it is silently
>> broken on many architectures (mainly 32-bit ones.)
>
>I understand that it's not portable in general, as there are many
>architecture-specific quirks in the system call ABI.  But where there
>are other established libraries using it, I assume they're already
>dealing with those quirks.  Also, the newer system calls that are
>likely to be called this way are less quirky, aren't they?
>
>I think that if we can *cheaply* implement a glibc API that allows more
>software to build and run on klibc with fewer changes, then we should.
>
>Ben.
I'm not so sure they have dealt with it in the sense of having it work on
all architectures. *Most* of the problems are related to the shifting the
arguments by one, which can cause a bunch of problems, especially if it means
the arguments spill to memory. However, I have absolutely no idea how to
correctly implement syscall(3) on s390 without a full table.

It is of course possible to implement using stdarg.h and a big switch statement,
but that is anything but cheap.

Now, thinking about it, it *might* be possible to implement some of this using
varadic macros. Let me play around with it a little bit.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 2020-07-27 19:20, hpa at zytor.com wrote:
> 
> I'm not so sure they have dealt with it in the sense of having it work
on all architectures. *Most* of the problems are related to the shifting the
arguments by one, which can cause a bunch of problems, especially if it means
the arguments spill to memory. However, I have absolutely no idea how to
correctly implement syscall(3) on s390 without a full table.
> 
> It is of course possible to implement using stdarg.h and a big switch
statement, but that is anything but cheap.
> 
> Now, thinking about it, it *might* be possible to implement some of this
using varadic macros. Let me play around with it a little bit.
> 
This might actually work:

/*
 * Not prototyped on purpose, as (...) isn't a valid prototype.
 * __extension__ prevents erroring out due to lack of prototype.
 */
__extension__ extern long long ___syscall();
extern long ___syscall_num;

#define syscall(n, ...)					\
  (___syscall_num = (n), ___syscall(__VA_ARGS__))

... then have ___syscall() get the system call number from the memory variable
___syscall_num (If klibc were multithreaded it would have to be a thread-local
variable, of course) and call the common syscall handler code.

Interestingly enough, on i386 the prototypeless function appears to be called
with the regparm convention, not the varadic convention -- not a problem, just
a matter of which handler to call.

Still not entirely sure what to do with s390, nor have I audited all the other
architectures but perhaps there are ways around that.

	-hpa