Re: Why I want PTRACE_O_TRACESTOP option

["Indan Zupancic" <indan@nul.nu>]

On Fri, September 9, 2011 14:26, Indan Zupancic wrote:
> 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.

PTRACE_O_TRACESTOP only makes sense if it also affects auto-attach
SIGSTOPS, of course. I don't know if it does. It probably should.

Indan