Hello Eigene, On 9/19/18 7:12 PM, Eugene Syromyatnikov wrote: > This is a SPARC-specific syscall. > > Signed-off-by: Eugene Syromyatnikov <evgsyr@xxxxxxxxx> > --- > man2/execve.2 | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/man2/execve.2 b/man2/execve.2 > index 3103c0e..d2bb861 100644 > --- a/man2/execve.2 > +++ b/man2/execve.2 > @@ -620,6 +620,17 @@ It makes little sense for the program itself to check it, but tracers > may show it; that said, some architectures (such as s390/s390x) do not bother > setting proper return value during exec, and that's can be exposed, > if not handled by the tracer specifically. > +.PP > +On sparc/sparc64, there's also > +.BR execv () > +system call available (for compatibility with SunOS), it has the following > +prototype: > +.PP > +.in +4 > +.EX > +.BI "int execv(char *" filename ", char *const " argv "[]); > +.EE > +.in > .\" > .SS Interpreter scripts > A maximum line length of 127 characters is allowed for the first line in I think it's better to note this in exec(3), so I added the patch below. Thanks, Michael diff --git a/man3/exec.3 b/man3/exec.3 index 0d531e921..10f15f3dc 100644 --- a/man3/exec.3 +++ b/man3/exec.3 @@ -277,6 +277,13 @@ internally and were consequently not async-signal-safe, in violation of the requirements of POSIX.1. .\" https://sourceware.org/bugzilla/show_bug.cgi?id=19534 This was fixed in glibc 2.24. +.\" +.SS Architecture-specific details +On sparc/sparc64, +.BR execv () +is provided as a system call by the kernel +(with the prototype shown above) +for compatibility with SunOS. .SH SEE ALSO .BR sh (1), .BR execve (2), -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
