[dtrace-discuss] Asynchronous signal handling in fasttrap provider

[Adam Leventhal]

On Fri, Feb 16, 2007 at 09:59:05AM +0900, Saravanan S wrote:
> I looked at the ulwp_t structure and found that 40 bytes were allocated for
> the scratch space in i386. I understand we need to have space for the traced
> instruction,JMP to the next instruction and the alternate instruction
> sequence ending in a trap required for handling aysynchronous
> signal.Asshown clearly in fasttrap_isa.c's fasttrap_pid_probe function
> this accounts
> for 37 bytes. Does the remaining three bytes allocated of the total 40 bytes
> is used for someother purpose?

We only need 37 bytes, but since it was so close to a multiple of 8 I couldn't
help but round up...

> I am not able to understand what you mean by "overwritten if a traced
> instruction was executed from the signal handler". Does this mean that
> signal handler instructions(code) can also be dtraced using offset probes?
> .Or am i completely missing something?

Signal handlers are often just C functions which themselves may be traced
using the pid provider. Executing a traced function will overwrite the
scratch space so we can't redirect the flow of control while we're actively
executing instructions in the scratch space.

> In the code I find that when we reach dtrace_safe_defer_signal on an
> asynchronous signal we set the pc(eip) to the alternate execution
> sequence(t->t_dtrace_npc) which will trap in to the kernel. In the function
> dtrace_user_probe as part of the trap handling code we reset the AST flag.
> 
> if (curthread->t_dtrace_ast) {
> aston(curthread);
> curthread->t_sig_check = 1;
> }
> We then go forward and set the pc(eip) to curthread->t_dtrace_npc which i
> seems to point to the alternate instruction sequence.So do we again trap in
> to the kernel? Seems like i am missing something here, please elucidate.

The alternate instruction sequence traps into the kernel (I'd suggest going
through the presentation I referenced before as it explains this in more
detail).

> I find that in fbt_provide_module function of the fbt provider functions
> belonging to dtrace module are not eligible for instrumentation.
> 
> if (strcmp(modname, "dtrace") == 0)
>     return;
> 
> Doesn't this mean dtrace_safe_ prefix functions are also not eligible as
> this symbols should also belong to the dtrace module?

These symbols are in the unix module.

> >If, by some fluke, you think this was an overly terse response, check out
> >this presentation where I delved into some the implementation details of
> >the pid provider:
> >
> >  http://blogs.sun.com/ahl/entry/pid_provider_exposed
> 
> I had gone through the presenstation and it was really good. It would be
> really nice if you could add USDT implementation specifics also in the
> slides. I did read your blog entries on USDT implementation specifics
> as well which were very informative
> http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better
> http://blogs.sun.com/ahl/entry/the_mysteries_of_init
> Thank you for the same.

My pleasure. I'm glad to hear they were useful. May I ask why you're
investigating the internals?

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl