[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPNHn3rTjMcbNXRpZTBc-zEkmnnMJO2iem9-eUdBkyaquz88rw@mail.gmail.com>
Date: Sat, 7 Sep 2024 01:45:50 -0700
From: Jubilee Young <workingjubilee@...il.com>
To: oleg@...hat.com
Cc: akpm@...ux-foundation.org, apais@...rosoft.com, benhill@...rosoft.com,
ebiederm@...ssion.com, linux-kernel@...r.kernel.org,
romank@...ux.microsoft.com, ssengar@...rosoft.com, sunilmut@...rosoft.com,
torvalds@...ux-foundation.org, vdso@...bites.dev
Subject: Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc FS
> 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.
> 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.
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.
- Jubilee
Powered by blists - more mailing lists