rv when execve succeeds...

[Dmitry V. Levin]

On Wed, Aug 09, 2017 at 03:14:49PM -0400, DJ Delorie wrote:
> 
> "Dmitry V. Levin" <ldv at altlinux.org> writes:
> > This "= 0" has been printed all these years, so it's quite logical to
> > suppose that the user expects to see "= 0" and might be quite surprised
> > to see something else like "= 11" instead.
> 
> Well, it *used* to print 11, I suppose 0 is better than 11 :-)

I agree, 0 is definitely better than 11 in this context. :)

> >> Where in any of the traced
> >> programs is that "= 0" available for inspection?
> >
> > It's in the register.  On x86_64 it's %rax, on s390 it's %r2, etc.
> 
> It's not about whether they expect to see "= 0" vs "= 11" - it's about
> whether they expect to see *anything at all*.

I bet they do.

> I mean, at the C program level, does the user have access to that?

Yes, using __asm__ extension, but it's hardly the C program level.

> Should we be implying that execve() *returned* to the user's program?

It's returned to userspace, but in case of successful invocation the
return code is rather presented to the new program rather than returned.

> By using a syntax that implies return of control to the caller, we may
> be confusing the user into thinking that the exec failed, but returned a
> zero to their program.
> 
> We could add some other way of indicating success that doesn't imply
> control was returned to the caller, like printing " (success)" instead
> of " = 0" there.

If the kernel supports PTRACE_EVENT_EXEC (modern kernels do), we can
distinguish the case when execv() succeeded with return code 0 (or 11
or whatever else) from the unlikely case when execv() failed with
return code 0 (or 11 or whatever else).  I suppose these details would
confuse users rather than make things more clear, though.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20170809/06b17f1d/attachment.bin>