[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Q: utrace && ptrace_check_attach()

> But currently ptrace can wake up the tracee and then later it can be
> ptrace_stop()'ed again, in this case we can decrement ->group_stop_count
> twice for the same thread.

The behavior or the bookkeeping need to change so they are consistent.

> OK, forget about mt issues. Do you really mean PTRACE_CONT/etc must _not_
> wake up SIGNAL_STOP_STOPPED tracee ? This would be nice perhaps, but this
> means a serious user-visible change.

I'm talking about the UTRACE_STOP/utrace_control behavior here.

When we implement ptrace on top and then get to the nasty corners of
strange compatibility with old ptrace, we can figure out what the exact
user-visible ptrace semantics need to be.  We might just do those cleanly
on top, or we might need some special-case ptrace fiddling.  But what we
won't do is have ptrace do anything that confuses the utrace bookkeeping
or the signals bookkeeping, like the current wake_up_process() does.

> > Let's do it however makes the code taken all together come out cleanest.
> > From what you said before, it sounds like tracehook_finish_stop() would
> > help with that.
> OK, I'll send the patch.

Use tracehook_*_jctl for the name, so it pairs with notify_jctl (and/or
change both names).  I avoid using "stop" in the tracehook.h names because
it's not inherently clear when that means "job control stop semantics"
and when that means other kinds of stopping (like utrace_stop/ptrace_stop).
jctl keeps it clear that this is only part of the code paths used for POSIX
job control stops.

> I think it can.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]