----- On Nov 17, 2020, at 1:58 PM, Peter Oskolkov posk@google.com wrote:

My assumption here was that applications that are aware of the new API
will always provide three parameters, while older applications will
continue calling the syscall with two.

I can't think of a situation/architecture where this will break anything.

I think what Florian refers to here is if there would be a glibc library
wrapper exposing the system call to applications. There, the number of
arguments would matter. But it does not exist today.

In some sense, it's a good thing that there isn't such wrapper exposed
yet. It also makes me wonder whether exposing system calls directly as a
library ABI is a good thing. It appears that library ABIs have stronger
restrictions with respect to number and types of parameters than system
calls.

Thanks,

Mathieu

Thanks,
Peter


On Tue, Nov 17, 2020 at 10:44 AM Florian Weimer [off-list ref] wrote:

quoted

* Segher Boessenkool:

quoted

But this isn't variadic in the sense of "..." -- on Power that always
passes the unspecified arguments in memory, while in this case it just
passes in either two or three registers.  I don't know any arg where
that would not work, given the Linux system call restrictions.

This is similar to the "open" system call.

Exactly.  You cannot call the open function through a non-variadic
function pointer.  I've seen it cause stack corruption in practice:

commit c7774174beffe9a8d29dd4fb38bbed43ece1cecd
Author: Andreas Schneider [off-list ref]
Date:   Wed Aug 2 13:21:59 2017 +0200

    swrap: Fix prototype of open[64] to prevent segfault on ppc64le

    The calling conventions for vaarg are different on ppc64le. The patch
    fixes segfaults on that platform.

    Thanks to Florian Weimer who helped debugging it!

    Signed-off-by: Andreas Schneider [off-list ref]
    Reviewed-by: Stefan Metzmacher [off-list ref]

<https://git.samba.org/?p=socket_wrapper.git;a=commitdiff;h=c7774174beffe>

It is possible to implement the open function in such a way that it
does not have this problem (simply do not use the parameter save area,
using assembler if necessary), but it's another obscure step that libc
implementers would have to take.

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com