This is the mail archive of the archer@sourceware.org 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: ptrace improvement: PTRACE_O_INHERIT


On 02/16, Roland McGrath wrote:
>
> > 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

Yes, but I can' understand the next part:

> 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.

Could you spell please?

Just curious.

Oleg.


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