svn commit: r350017 - in head: lib/libc/sys sys/kern sys/sys tests/sys/kern

[Kyle Evans]

On Tue, Nov 26, 2019 at 6:18 PM John Baldwin <jhb at freebsd.org> wrote:
>
> On 11/25/19 11:01 AM, Kyle Evans wrote:
> > On Mon, Jul 15, 2019 at 4:48 PM John Baldwin <jhb at freebsd.org> wrote:
> >>
> >> Author: jhb
> >> Date: Mon Jul 15 21:48:02 2019
> >> New Revision: 350017
> >> URL: https://svnweb.freebsd.org/changeset/base/350017
> >>
> >> Log:
> >>   Add ptrace op PT_GET_SC_RET.
> >>
> >>   This ptrace operation returns a structure containing the error and
> >>   return values from the current system call.  It is only valid when a
> >>   thread is stopped during a system call exit (PL_FLAG_SCX is set).
> >>
> >>   The sr_error member holds the error value from the system call.  Note
> >>   that this error value is the native FreeBSD error value that has _not_
> >>   been translated to an ABI-specific error value similar to the values
> >>   logged to ktrace.
> >>
> >>   If sr_error is zero, then the return values of the system call will be
> >>   set in sr_retval[0] and sr_retval[1].
> >>
> >>   Reviewed by:  kib
> >>   MFC after:    1 month
> >>   Sponsored by: DARPA
> >>   Differential Revision:        https://reviews.freebsd.org/D20901
> >>
> >> Modified:
> >>   head/lib/libc/sys/ptrace.2
> >>   head/sys/kern/sys_process.c
> >>   head/sys/sys/ptrace.h
> >>   head/tests/sys/kern/ptrace_test.c
> >>
> >
> > Hey John,
> >
> > Any objection to MFC'ing this to stable/12 at least? I've found this
> > to be almost-required in the ptrace user I've been working on
> > lately... I certainly ripped out plenty of hair before realizing that
> > it wasn't detecting error returns properly.
>
> Hmm, I did have it in my queue, but not the most urgent priority.   Are
> you using truss or something else?  You can achieve the same thing without
> the new op, it just requires arch-specific code to fetch the error status
> and return value from registers.
>

Alrighty- that's good to hear. =-)

It's actually an out-of-tree ptrace(2) user that's executing syscalls
in the process it's attaching to. It works most of the time because
the syscalls it's executing don't generally fail (mmap a single page
was the only use until I started dorking with it), so it's not quite
worth the overhead of adding the arch-specific bits to detect error
(it grabs the return value, at least) -- this is generally just a
small nicety for those of us debugging it.

Thanks,

Kyle Evans