This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 'catch syscall' Status

I'll explain the ptrace picture for this fully here.
I'll pick up the other thread wrt the "phase 2" parts.

If the kernel does not grok this flag, don't try to support the feature.

Each place you'd use PTRACE_CONT, use PTRACE_SYSCALL instead.
Parameters are the same (signal number).

When you get a WIFSTOPPED wait status, its WSTOPSIG will be SIGTRAP|0x80
for a syscall stop.  There is one of these before each syscall and one after.
You have to keep track of your own toggle to remember whether you're next
expecting a before-syscall or an after-syscall stop.  Note that some of the
other PTRACE_O_* stops come in the middle of a syscall, so the after-syscall
stop won't always immediately follow the before-syscall stop.  However,
you can be sure that no ordinary signal stops will come in between.

At the before-syscall stop, there is a machine-specific magic way to fetch
the system call number.  (Ask me about each machine and I can tell you what
it is.)  The syscall parameters are in the normal registers and/or memory.
(Phase 2 subject to worry about where exactly.)

At the after-syscall stop, there is a machine-specific magic way to tell
whether the syscall succeeded or failed, and to extract the number that
will wind up in errno (to pass to strerror, e.g.).  When the syscall
succeeded, its return value is in the machine's standard return value
register for a function returning long int.

Both of these stops show the PC at the insn following the syscall insn,
i.e. what's really the "return PC to caller" from the syscall.

These stops mean "user did the syscall insn" and "about to resume after the
user did the syscall insn".  So they happen even if the syscall number is
bogus.  A bogus syscall number acts like a real call that fails with ENOSYS.

At the after-syscall stop, the registers might show that the syscall failed
with an errno value that's one of the ERESTART* codes ([512,516], not
defined in userland or known to strerror).  These are not real errors that
the code making the syscall can ever see.  These all mean that the syscall
stopped because of signal interruption.  After we resume from the
after-syscall stop, there will probably be an immediate signal stop.  (It's
not certain there will be, due to some MT situations.)  Either the user PC
will be backed up to start the same syscall insn over again, or the error
code register will be changed to show EINTR.  This is done after the
PTRACE_SYSCALL stop, but before the user's calling code or its signal
handler can ever see the register state.

The interactions with single-step get slightly stranger.
I can get into that subject when you want to know.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]