[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.020 / U:39.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site