Page MenuHomeFreeBSD

Add ptrace op PT_GET_SC_RET.

Authored by jhb on Jul 9 2019, 11:06 PM.


Group Reviewers
rS350017: 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].

Test Plan
  • also tested by truss changes as well as new test on i386 and amd64

Diff Detail

rS FreeBSD src repository - subversion
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

  • Document PT_GET_SC_RET.
79 ↗(On Diff #59586)

Can we rely on ptrace_sc_ret32 having the same layout as ptrace_sc_ret ? This would simplify the code, but would make a possible extension harder.

1080 ↗(On Diff #59586)

Excessive ()

162 ↗(On Diff #59586)

May be add some pad ints for future ?

79 ↗(On Diff #59586)

You mean if we used uint64_t instead of register_t? I don't know that it really helps to make it uint64_t. In particular for CHERI these have to become 128-bit types. I do pass the size in 'data' at least. On the other hand, I don't expect this structure to grow aside from supporting different ABIs like CHERI. We aren't going to add more return values from system calls.

162 ↗(On Diff #59586)

I don't think we will need them?

I did just have a thought btw that we could perhaps choose to extend ptrace_lwpinfo with new fields for this instead of adding a new ptrace op since the return values are fixed size unlike syscall args. I think I probably still prefer a separate op, but I hadn't considered extending lwpinfo until just now.

I think the present approach is cleaner than adding one more special case for lwpinfo.

This revision is now accepted and ready to land.Jul 10 2019, 12:10 AM
This revision was automatically updated to reflect the committed changes.