On 02.01.2017 18:54, David Holland wrote:
> On Mon, Jan 02, 2017 at 05:18:49AM +0100, Kamil Rytarowski wrote:
> > > Historically exect() is used by debuggers to start debuggees. While
> > > it's equivalent to using PT_TRACE_ME followed by execve(), I think the
> > > result is that the new process first stops immediately after the exec
> > > finishes so that the debugger doesn't have to worry about stepping
> > > through the exec call in its own code.
> > >
> > > This doesn't mean it shouldn't go away (or as much away as it can,
> > > that is, to COMPAT_70) but I'm not convinced there's no case for it.
> > >
> >
> > So, can I change exect(3) to something like:
> >
> > int
> > exect(const char *path, char *const argv[], char *const envp[])
> > {
> > if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
> > return -1;
> > return execve(path, argv, envp);
> > }
> >
> > The current implementation of exect(3) (at least philosophically)
> > predates SIGTRAP on exec().
>
> Not really; AFAIK, with that the target will first stop at the return
> from the ptrace call, and also stop at the exec, whereas with
> traditional exect it will first stop after the exec completes, in
> __start or in ld.elf_so.
>
> An unsophisticated debugger expecting the latter will almost certainly
> be confused by the former.
>
> Anyway, it needs to be kept in both the kernel and libc for compat so
> there's not much to be gained by mucking with it. :-/
>
A debugger doesn't catch signal on PT_TRACE_ME. It will stop once on exec().
I don't see any need for compat as I doubt that it was ever functional.
In the past it was trying to singlestep libc call for execve(2), with
the new approach it will not turn on PT_STEP, but emit signal on exec().
Attachment:
signature.asc
Description: OpenPGP digital signature