Re: [RFC] Proposal for ptrace improvements

[Tejun Heo <tj@kernel.org>]

Hello,

On Fri, Mar 04, 2011 at 02:59:32PM +0100, Denys Vlasenko wrote:
> I would rather speed strace up than slow it down further, even if
> slightly.

The question to ask is at what cost?  If mostly unnoticeable slow down
makes the API cleaner, I'll go that way.  Everything is a tradeoff.

> > it might really not fit there.  I'd like to avoid twisting debugging
> > API
> 
> It is *already* twisted that way. Other ptrace stops *already*
> return extra information in waitpid status: run "man ptrace"
> and read PTRACE_SETOPTIONS section. For example:
> 
>       "PTRACE_O_TRACEEXEC (since Linux 2.5.46)
>              Stop  the  child  at  the next execve(2) call with
>              SIGTRAP | PTRACE_EVENT_EXEC << 8."
> 
> I don't see why adding another PTRACE_EVENT_foo
> is a big deal.

No, I wasn't talking about that.  My concern was that.  Let's say, we
need a flag somewhere to indicate group stop state (because the state
is necessary regardless of which trap is taken) and then we can't or
that to SIGTRAP transparently because that would change it for the
existing events and at the same time I don't want to make the
information available in two separate forms.

That said, I think, for strace, it should be okay.  Unless the tracer
resumes the tracee while job control stop is in effect, the trap which
is taken after SIGCONT emission will be a new distinguishible trap
which will be assigned a separate PTRACE_EVENT_*, so it wouldn't have
to depend on siginfo.

Anyways, I'll keep the distinction performance on mind but if it comes
down to API convolution, I don't think bending that way is a good
idea.  If we're gonna bend, there should be numbers justifying the
bending.

Thanks.

-- 
tejun