Re: utrace-based uprobes

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Thu, 2007-03-15 at 17:21 -0700, Jim Keniston wrote:
> o As of now, uprobes aren't inherited across fork()s.

Is there a special reason for this? It looks like you currently do extra
work in case of a fork() to remove the breakpoints, which most likely
will be cleared anyway as soon as the thread does an exec().

> o Probe registration and ungregistration in the context of a
> multithreaded application, are asynchronous events. All threads
> need to be QUIESCED before the program text is modified to insert
> the breakpoint.

Is this a requirement? I suppose modifying code while another thread can
execute that code path is never safe. But do you have to suspend all
threads? A suggestion would be to mark the code page as not executable
so any thread that accesses that code path gets trapped till the code
has been adjusted.

> +When a CPU hits the breakpoint instruction, a trap occurs, the CPU's
> +user-mode registers are saved, and a SIGTRAP signal is generated.
> +Uprobes intercepts the SIGTRAP and finds the associated uprobe.

One problem that I recently encountered is that the process might have
SIGTRAP masked or you might insert and then hit a breakpoint while a
SIGTRAP handler is running in the user process (which normally means the
handler is masked and hitting the breakpoint will then most likely kill
the process completely). I don't know a way around this. If you can
detect such a case you would need to enter the kernel differently. On
the other hand this might not be a very common case. But it might be
something you want to keep in mind.

> +If the number of times a function is called does not match the
> +number of times it returns (e.g., if a function exits via longjmp()),
> +registering a return probe on that function may produce undesirable
> +results.

What do these undesirable results include (is it unsafe to add return
probes)? Is there a way to detect such functions/behavior?

> +When you register the first probe at probepoint or unregister the
> +last probe probe at a probepoint, Uprobes asks Utrace to "quiesce"
> +the probed process so that Uprobes can insert or remove the breakpoint
> +instruction.  If the process is not already stopped, Utrace sends it
> +a SIGSTOP.  If the process is running an interruptible system call,
> +this may cause the system call to finish early or fail with EINTR.

Is this a limitation of utrace at the moment? Or will it be possible in
the future for utrace to "quiesce" a process without a "user visible"
SIGSTOP signal?

Cheers,

Mark