On 10/20, Roland McGrath wrote:
>
> > But ptrace_check_attach() needs the tracee to be already stopped.
> > A bit ugly to ask the tracee to stop via UTRACE_STOP and then resume
> > it if it was not already stopped. And I don't even understand how to
> > do this correctly. (but again, I'll try to th
> But ptrace_check_attach() needs the tracee to be already stopped.
> A bit ugly to ask the tracee to stop via UTRACE_STOP and then resume
> it if it was not already stopped. And I don't even understand how to
> do this correctly. (but again, I'll try to think later).
Ugly, but correct and simple.
On 10/15, Roland McGrath wrote:
>
> > > And then you check whether it's really in a proper ptrace stop, see that
> > > it
> > > isn't, and use UTRACE_RESUME.
> >
> > So far I don't really understand to do this correctly, but OK.
>
> I guess I'm missing something because it seems trivial to me.
Mo
> > And then you check whether it's really in a proper ptrace stop, see that it
> > isn't, and use UTRACE_RESUME.
>
> So far I don't really understand to do this correctly, but OK.
I guess I'm missing something because it seems trivial to me.
> ptrace_check_attach() does verify we are ptracer. I
On 10/12, Roland McGrath wrote:
>
> > Suppose a tracee is running, but for some reason it is somewhere
> > inside start_callback(). utrace_control(UTRACE_STOP) can change ->flags
> > and provoke report->action = UTRACE_STOP. In this case the tracee will
> > stop.
>
> And then you check whether it's
> Not sure I understand... This is behaviour change, no?
No, I'm not talking about any change in the user-observable semantics.
> Suppose a tracee is running, but for some reason it is somewhere
> inside start_callback(). utrace_control(UTRACE_STOP) can change ->flags
> and provoke report->action
On 10/11, Roland McGrath wrote:
>
> > Issues with ptrace_check_attach(),
> >
> > - it does utrace_control(UTRACE_STOP).
> >
> > This is wrong, ptrace_check_attach() must be "passive",
> > while utrace_control(UTRACE_STOP) can actualy stop the
> > tracee.
>
> This is not inhere
> Issues with ptrace_check_attach(),
>
> - it does utrace_control(UTRACE_STOP).
>
> This is wrong, ptrace_check_attach() must be "passive",
> while utrace_control(UTRACE_STOP) can actualy stop the
> tracee.
This is not inherently problematic on its own. I'd say it'
Issues with ptrace_check_attach(),
- it does utrace_control(UTRACE_STOP).
This is wrong, ptrace_check_attach() must be "passive",
while utrace_control(UTRACE_STOP) can actualy stop the
tracee.
- even if it doesn't, this is wrong when we have multiple
