User: Password:
|
|
Subscribe / Log in / New account

More than one process executing the same object code

More than one process executing the same object code

Posted Jan 21, 2010 12:13 UTC (Thu) by epa (subscriber, #39769)
Parent article: Uprobes: not quite there yet

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.


(Log in to post comments)

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 (guest, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds