This is the mail archive of the
mailing list for the Archer project.
Re: ptrace improvement: PTRACE_O_INHERIT
> 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