----- On Nov 17, 2020, at 1:58 PM, Peter Oskolkov posk@xxxxxxxxxx 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 <fw@xxxxxxxxxxxxx> wrote: >> >> * Segher Boessenkool: >> >> > 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 <asn@xxxxxxxxx> >> 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 <asn@xxxxxxxxx> >> Reviewed-by: Stefan Metzmacher <metze@xxxxxxxxx> >> >> <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
