Re: Why I want PTRACE_O_TRACESTOP option

From: Indan Zupancic
Date: Fri Sep 09 2011 - 08:27:05 EST


Hello,

On Fri, September 9, 2011 07:54, Denys Vlasenko wrote:
> On Friday 09 September 2011 02:18, Tejun Heo wrote:
>> Hello, Denys.
>>
>> On Thu, Sep 08, 2011 at 06:50:01PM +0200, Denys Vlasenko wrote:
>> > Consider what will happen when a next ptrace fix will require
>> > a way to change ptrace API at runtime. A new option will likely
>> > be introduced, say, PTRACE_O_TRACEPONY, with next available
>> > bit position 7, and perhaps some new event will be generated,
>> > PTRACE_EVENT_PONY, with value.... yes, it can't be 7,
>> > PTRACE_EVENT_STOP took it. So it will probably be 8.
>>
>> Then, just give it the next matching number.
>
> My point is that previously, ptrace behavior was modified by setting
> options. Why don't we use this mechanism? Why we invent a different
> wheel? Ptrace is ugly as-is, why complicate it even further?
>
> The argument was that SETOPTIONS wasn't suitable for modifying
> attach behavior, but this is fixed by "set options on SEIZE"
> patch. I don't see why we can't use options mechanist to affect
> group-stop behavior now.

I totally agree with Denys here.

It is very useful to set options atomically at SEIZE time. Having
SEIZE set some hidden option implicitly only makes things more
confusing and harder to explain what SEIZE does. Please apply Denys'
SEIZE API improvements.

Another important reason to make PTRACE_O_TRACESTOP an option is
because not everyone uses SEIZE: Users using PTRACE_TRACEME can't
set this option at all. For those PTRACE_O_TRACESTOP is needed.
Using PTRACE_TRACEME is the common case for both strace and gdb.

That is an indication that mixing up the setting of an option with
a specific attach request is wrong.

Greetings,

Indan


P.S. It seems messages to tj@xxxxxxxxxx have trouble getting through,
I hope they arrive eventually.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/