[dtrace-discuss] Asynchronous signal handling in fasttrap provider

[Saravanan S]

On 2/19/07, Adam Leventhal <ahl at eng.sun.com> wrote:
>
> 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.


Thanks for the explanation.

> 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?


Firstly, i am interested in knowing the internals of Dtrace. I am also trying to
investigate how much easy it is to port Dtrace on a different
architecture or a OS apart from
SPARC/x86. I did find that the source code is clearly organised in to ISA
specific and platform independent code.I did learn that Dtrace was ported on
to Mac OS X(Xray) for the x86 architecture.  I tried to find the Xray source
code,
but i was not able to. I am not sure whether the Xray  code is open or
not. It would be nice if
you, the dtrace community and the Apple Dtrace team can
share your thoughts about porting Dtrace to a different
architecture/OS, the possible pitfalls that could
be encountered etc.,

Thanks
Saravanan S

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



-- 
Subscribe LKG_INDIA Group :
Its Linux Kernel oriented group, started by bunch of
guys from India.This group discusses the technical details of Linux
Kernel, helping the members to share and enhance their knowledge on Linux
Kernel and general OS concepts.
Be a member of it if you are Linux Kernel Geek.
Visit the LKG_INDIA home page:
http://groups.yahoo.com/group/lkg_india/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070218/01c7ac28/attachment.html