[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/10] ptrace: implement PTRACE_SEIZE
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

 \ /
  Last update: 2011-05-20 10:59    [W:0.124 / U:1.856 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site