Re: ptrace improvement: PTRACE_O_INHERIT

[Roland McGrath <roland@redhat.com>]

> That may be too asynchronous.  After GDB/gcore/etc. finishes new PTRACE_ATTACH
> must complete successfully.  I never know if it is already guaranteed or not
> but in practice it works now.

Sorry if I was unclear, that is not the kind of asynchrony I was talking
about.  It is guaranteed now that when PTRACE_DETACH succeeds, the tracee
is detached and can be attached anew.  That would be true of what I
suggested also.  The asynchrony I mean is the good kind: that it doesn't
have to be stopped for you to detach it.  

There is nothing special for a debugger to worry about with this
asynchrony unless it uses multiple threads where one thread calls wait*
while another thread calls ptrace.  In that case, the debugger's wait*
thread could see a stop result that appears to be after its other thread
detached the same tracee.  (That is already true now with PTRACE_DETACH.)
If the debugger's own wait* call is strictly ordered after its detaching
ptrace call, there can be no such confusion.

> If there is no PTRACE_DETACH_ALL_TIDS(pid) and PTRACE_O_THREAD_INHERIT is in
> use GDB probably has to repeatedly iterate /proc/PID/task/*/status till all
> have TracerPid == 0.

Indeed.  That seems undesireable.

> > the attach-group implementation will be sufficiently hairy that the kernel
> > community would demand that we do some simpler incremental changes first
> > before attempting it (such as what I proposed for ATTACH_NOSTOP, which
> > eliminates the SIGSTOP and rolls in atomic option-setting).
> 
> thread_db_find_new_threads_2 already does an ugly loop of repeated threads
> finding.  There are also some failures that can be probably fixed by changing
> td_ta_thr_iter to readdir(/proc/PID/task) (RH#677654).  There are some pending
> bugs in GDB about it.

I take that to mean that you do not see a strong demand for a
group-attach feature, though having one would simplify things.
(But since GDB will never get rid of its code to support older
kernels, perhaps such simplification doesn't really help much
in practice.)


Thanks,
Roland