Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc FS

["Eric W. Biederman" <ebiederm@xmission.com>]

Jubilee Young <workingjubilee@gmail.com> writes:

>> if the process is ptraced, debugger can insert the breakoint into
>> please_insert_the_breakpoint_here(). Otherwise breakpoint_if_debugging()
>> is a cheap nop.
>
> Generally a programmer wants to put this kind of conditional breakpoint
> on an exception path, for which, unless one is working with a language that
> abuses exceptions for control flow (which unfortunately describes... many),
> the performance isn't of enormous concern. Not that it's free, either, but
> opening a file and scanning it is a lot more code than a single call
> to prctl.

I want to reiterate what Oleg pointed out elsewhere in this
conversation.

Observing a process is ptracing the current process does not mean a
debugger is attached to the current process.  It could be strace, or
upstart or some other code that happens to use the ptrace facility.

Which in turn means that opening /proc/self/status and looking for
TracerPid does not reliably detect if a debugger is attached.

Which unfortunately means that this must be solved as a coopeartive
effort between the library implementation and the debuggers.  Nothing
else can reliably tell you that a debugger is attached to your process.




Which in turn means this can not be solved in the kernel.  It must
be done as a cooperative effort between the implementation of the
library and the debuggers.

>> Perhaps it makes sense to discuss the alternatives? Say, a process can have a
>> please_insert_the_breakpoint_here() function implemented in asm which just does
>> asm(ret).
>
> There's some merit in having the debuggers recognize this pattern, as that
> then would save every language that wants to have this power available
> the trouble of reimplementing it. But first debuggers must recognize it,
> which would require teaching each of them, which can be... tedious.

Unfortunately that is the only solution that I can see that will work
reliably.

> Having a function named `fatal` or whatever likewise has this issue.
> A toolchain, however, can simply insert a jump to a breakpoint easily,
> without having to hold gdb, lldb, cdb, and whatever-other-db's hand.

Eric