Page MenuHomeFreeBSD

Add ptrace op PT_GET_SC_RET.
ClosedPublic

Authored by jhb on Jul 9 2019, 11:06 PM.
Tags
None
Referenced Files
F80166266: D20901.id.diff
Thu, Mar 28, 7:29 PM
Unknown Object (File)
Feb 12 2024, 4:00 PM
Unknown Object (File)
Jan 8 2024, 11:54 PM
Unknown Object (File)
Jan 8 2024, 11:54 PM
Unknown Object (File)
Jan 8 2024, 11:54 PM
Unknown Object (File)
Jan 8 2024, 11:53 PM
Unknown Object (File)
Jan 8 2024, 11:38 PM
Unknown Object (File)
Dec 20 2023, 2:12 AM
Subscribers

Details

Reviewers
kib
Group Reviewers
manpages
Commits
rS350017: Add ptrace op PT_GET_SC_RET.
Summary

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

Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 25276
Build 23942: arc lint + arc unit

Event Timeline

  • Document PT_GET_SC_RET.
sys/kern/sys_process.c
79

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

Excessive ()

sys/sys/ptrace.h
162

May be add some pad ints for future ?

sys/kern/sys_process.c
79

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.

sys/sys/ptrace.h
162

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.