I do not see where execve* differ from other system calls (except exit*, of course, which are indeed different), they put their return code the same way as other system calls do, and strace indeed retrieves and shows it. I assume, process (right at the entry point) can check it as well as return code of any other system call (I'm not saying that it may be useful, however).

Except execve*() doesn't have a return code when it doesn't return (i.e. when it successfully exec's a new process).  A return code shouldn't be printed at all in that case.  This is similar to how exit() is handled.

If execve*() fails to exec a process, then yes, the return value should be reported just like any other syscall.

Well, what I see in [1], which is called from [2], which is called from [3], is a bunch of work related to process image replacement, with a return at the end in case of success [4]. The fact that the old process image is non-existent at the moment of return is a minor detail, which is unrelated to the fact that syscall does return (to the entry point of the new image). And, at the moment execve() returns, ptrace syscall-exit-stop occurs and strace is notified about it (note that PTRACE_EVENT_EXEC is largely ignored and is used mostly for handling possible pid change on old kernels and supporting detach-on-execve functionality). So, the fact that strace prints 11 as execve return code means that something is not good (ELF loader explicitly sets retval to 0 at the end of load, so it's probably different image format or something else, maybe something on arch-specific exit path).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c#n1682
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c#n1828
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c#n1910
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c#n1804

If execv fails for any reason, sure, print a return code.

As for the success case, which is all this issue is about, the "minor detail" about the caller not existing is the crux of the issue - the call the caller makes doesn't return to the caller.  IMHO this is all about the traced process's point of view, since that's the expectation the strace user has.  But, if we've gotten to this point in the philosophy, it's time to bring the issue up upstream and let them decide which semantics make more sense for the typical user.

Also, if the value of zero is just a coincidence (the 11 from bz1220802 indicates this might be so), then printing arbitrary values is still a bug.  However, I've posted the philosophical part of the question upstream:

https://sourceforge.net/p/strace/mailman/message/35989051/

The result of the upstream discussion is that execve *does* return a success code, despite the code being returned to the new image and not the old one (and being difficult, but not impossible, to access), and thus printing " = 0" is appropriate.

I.e. strace is considering the call from the kernel's point of view, not the POSIX C API point of view.

(In reply to DJ Delorie from comment #5)
> https://sourceforge.net/p/strace/mailman/message/35989051/

A note to myself: this thread in the mail list archive on lists.strace.io:

https://lists.strace.io/pipermail/strace-devel/2017-August/007230.html