Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

[Pedro Alves]

On Friday 20 May 2011 02:44:44, Denys Vlasenko wrote:
> > > > In GDBs case, GDB will want to poke at memory
> > > > right after attaching
> > > 
> > > ...where "right after attaching" is defined as "when the first ptrace-stop
> > > is reported". Which will happen very soon.
> > 
> > Hmm?  Why would it happen very soon?
> > Isn't the point of SEIZE not 
> > interrupting that you'd not get any INTERRUPT or stop at all?
> > Where is the ptrace-stop coming from?
> 
> From PTRACE_INTERRUPT. Without it, tracee is running. 

> Ptrace API never allowed poking of running tracees.

Which is a bit lame.

> You need to stop it first.

That was my point...  I was just pointing out that GDB will end
up PTRACE_INTERRUPTing the target anyway.  Maybe we could extend
GDB's "observer" mode to be even more observer-only, and delay
reading the DSO list and whatever else GDB does on attach until
the first stop, or to user request.  Some archs need reading
registers as soon as possible in order to actually know which
arch variant we've attached to.  Anyway, this is GDBs business.
SEIZE not interrupting won't hurt GDB, and is obviously useful for
some use cases and tracers, _provided the race with SETOPTS is fixed_.

-- 
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/