LWN: Comments on "Uprobes: not quite there yet"

More than one process executing the same object code

oak — Wed, 17 Feb 2010 19:17:28 +0000

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.

Uprobes: not quite there yet

oak — Wed, 17 Feb 2010 19:14:48 +0000

Even the SSOL approach one needs to "emulate" / "fix" those of the
instructions which use relative addressing, see Roland's old mail on the
subject:
http://sourceware.org/ml/systemtap/2007-q1/msg00571.html

And the instructions are of course architecture specific.

The good thing is that if one puts breakpoints just on function entry &
exit points, those usually use fairly small set of instructions. See e.g.
this user-space function tracing utility that uses SSOL with breakpoints:
http://repository.maemo.org/pool/fremantle/free/f/functra...

If breakpoints can be put anywhere, it's more of an issue. Good question
is how to test that emulation of all the required instructions for SSOL
works fine...

Uprobes: not quite there yet

Tobu — Thu, 21 Jan 2010 19:41:45 +0000

Executables don't control their address space entirely, every library reserves some pages.

Could the extra address space be reserved once by a library everyone links to, the libc? Utrace would write the displaced instructions into that shared space, which the process has no control over. No VMA is introduced while the process is running.

Though that requires some coordination. It's more convenient to let the kernel do the reservation. But it can be done very early to not interfere with the process and its libraries.

meh

Tobu — Thu, 21 Jan 2010 19:02:59 +0000

The point of probes is that ls won't notice the extra few instructions. With some filtering at a privileged level, the prober won't see leaked information either.

file tracing considered harmful???

faramir — Thu, 21 Jan 2010 17:57:13 +0000

If I understand the suggestion that executable files should have probes attached rather then processes, then I'm against it. What if I want to attach probes when a particular user (who has a use case that triggers problems) executes 'ls' or some other frequently executed program? What happens when everyone else executes 'ls'? I admit I really don't know how probes work, but it would worry me a lot if there wasn't some way to probe installed binaries without affecting all other users of that binary. Please tell me I shouldn't be worried.

Uprobes: not quite there yet

bronson — Thu, 21 Jan 2010 16:45:59 +0000

Suddenly I'm reading the project's name as UpRobes. That might be even more descriptive. :)

Can anyone name an existing app that might break with the foreign memory area in its address space? Based on this article, the complaints about XOL sound awfully obscure.

Adding an emulator to the kernel just for this?? That would be an endless source of problems!

More than one process executing the same object code

rvfh — Thu, 21 Jan 2010 13:24:51 +0000

I believe the problem also exists for multithreaded processes...

More than one process executing the same object code

epa — Thu, 21 Jan 2010 12:13:02 +0000

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.

Uprobes: not quite there yet

chantecode — Wed, 20 Jan 2010 23:58:50 +0000

We are not telling people to develop plugins for perf _instead_ of ftrace. The former doesn't supersedes the latter. They are complementary. ftrace is not deprecated. What is deprecated (in most cases) is the old ftrace plugin system (struct tracer) for new tracing code, altough it's still relevant for older tracers like function, mmiotrace, etc... Instead we recommend to use the ftrace trace event API because it is much more powerful, and it also creates events directly usable by perf.

Thanks,

Frederic.