As I understand the article, a lot of the problems occur because more than one process might share the same page of object code (or 'text'), and so it's not possible to modify it without disrupting other processes that aren't being probed. But why not just require that a process being probed must have its own, unshared copy of the code it executes? On a modern system losing ten megabytes or so for a duplicate copy of your program and its shared libraries is not a big deal. Or perhaps some kind of copy-on-write system could be used for these pages, so only the one page modified to insert the probe need be unshared between processes?
I'm sure the kernel hackers have considered all this but the article doesn't mention why a simpler solution isn't possible.
More than one process executing the same object code
Posted Jan 21, 2010 13:24 UTC (Thu) by rvfh (subscriber, #31018)
[Link]
I believe the problem also exists for multithreaded processes...
More than one process executing the same object code
Posted Feb 17, 2010 19:17 UTC (Wed) by oak (subscriber, #2786)
[Link]
The problem with multithreaded programs is that if you disable breakpoint
to let program continue, you might miss the other threads passing that
instruction. SSOL solution leaves the breakpoint in place and
runs/emulates the instruction overwritten by the breakpoint from
elsewhere.