dtrace discuss - Mar 2007 - Dtrace probes in ksh93 (was: Re: Dtrace with line numbers?)

On 3/11/07, Rayson Ho <rayrayson at gmail.com>
wrote:
> On 3/11/07, Michael Shapiro <mws at zion.eng.sun.com> wrote:
> >  A useful community
> > project would be CTF extensions or pluggable libraries for Sun and GNU
> > tools to provide access to line number data from the various
compilers.
>
> How about a Google Summer of Code project??
I''d rather go for the GSC project to add Dtrace probes to ksh93 but I
don''t know the ksh93 sources that well and need help.

Cheers,
William
-- 
    @,,@   William James
   (\--/)  williamjamesgnusolaris at gmail.com
  (.>__<.) GNU/Solaris hacker

William James wrote:
[CC:''ing summerofcode at opensolaris.org]
> On 3/11/07, Rayson Ho <rayrayson at gmail.com> wrote:
> > On 3/11/07, Michael Shapiro <mws at zion.eng.sun.com> wrote:
> > >  A useful community
> > > project would be CTF extensions or pluggable libraries for Sun
and GNU
> > > tools to provide access to line number data from the various
compilers.
> >
> > How about a Google Summer of Code project??
> 
> I''d rather go for the GSC project to add Dtrace probes to ksh93
but I
> don''t know the ksh93 sources that well and need help.
I am currently trying to figure out how the "Google Summer Of Code"
stuff works.

The complexity/difficulty of getting DTrace probes implemented depends
on the type of probe. AFAIK the degree of difficulty looks like this
("1"=easy, "10"=godlike knowledge of universe required):

1. "xtrace" probe (just prints what the "xtrace" mode of the
shell would
print)

2. Trace subprocess creation and exit (e.g. fork())

3. Trace subshell creation and destruction (subshell!=child process in
ksh93)

4. Trace shell function calls

5. Trace calls to external commands and builtin commands

6. Get stacktrace of running shell (e.g. in which shell function or
builtin command ksh93 is currently running in)

9. Track the creation/destruction of shell functions

10. Trace get/set/unset of all variables (AFAIK very hard (assuming we
want to track both set/get/unset from shell level and all ways of
internal set/get/unset+libshell''s API) since there is no central place
within libshell to trace this - partially C functions, macros or direct
access is used for this)


AFAIK anything from [1]-[5] is good for a "Google Summer Of Code"
project but anything with a higher degree of difficulty may be too
much...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

> The complexity/difficulty of getting DTrace probes implemented depends
> on the type of probe. AFAIK the degree of difficulty looks like this
> ("1"=easy, "10"=godlike knowledge of universe
required):
> 
> 1. "xtrace" probe (just prints what the "xtrace" mode
of the shell would
> print)
Why is it useful to duplicate the functionality already provided by xtrace 
mode?
 
> 2. Trace subprocess creation and exit (e.g. fork())
Can''t DTrace do it now using existing probes?
 
> 3. Trace subshell creation and destruction (subshell!=child process in
> ksh93)
Ditto.
 
> 4. Trace shell function calls
This seems like a real value for any interpreted language.
 
> 5. Trace calls to external commands and builtin commands
For builtins - yes. For external commands existing facilities may be 
sufficient.
 
- Alex Kolbasov

Alexander Kolbasov wrote:
> > The complexity/difficulty of getting DTrace probes implemented depends
> > on the type of probe. AFAIK the degree of difficulty looks like this
> > ("1"=easy, "10"=godlike knowledge of universe
required):
> >
> > 1. "xtrace" probe (just prints what the "xtrace"
mode of the shell would
> > print)
> 
> Why is it useful to duplicate the functionality already provided by xtrace
> mode?
AFAIK dtrace can be attached to an already running process, right (note:
I am not familar with dtrace...) ? Using the normal "xtrace" option of
a
shell requires to (re-)start the shell with that option and doesn''t
help
to look into an already running script (for example to figure out why
the shell script is running amok or to get something like "profiling"
data).

Another problem is that "xtrace" slightly alters the behaviour of a
script because it sends it''s debugging output to stderr. If stderr is
linked to /dev/null or used for something else it''s becoming tricky...
> > 2. Trace subprocess creation and exit (e.g. fork())
> 
> Can''t DTrace do it now using existing probes?
AFAIK the existing probes won''t show you the shell variables (not ENV)
passed to a child process. Another issue is that ksh93 doesn''t have an
1:1 binding of subshell==subprocess, instead subprocesses are only
created if they are really needed.
> > 3. Trace subshell creation and destruction (subshell!=child process in
> > ksh93)
> 
> Ditto.
Creating a subshell in ksh93 usually does not create a child process
(except for background jobs or when a subprocess is needed later),
instead the current view of shell variables/status/etc. is saved in a
"context" which gets restored later when the subshell exists
(disclaimer: that''s only a simplicication and not how the
implementation
works).
IMO it would be usefull to have a probe which tracks the
creation/destruction of subshells independently since this affects the
status of variables and other shell states.
> > 4. Trace shell function calls
> 
> This seems like a real value for any interpreted language.
> 
> > 5. Trace calls to external commands and builtin commands
> 
> For builtins - yes. For external commands existing facilities may be
> sufficient.
Uhm... no. IMO three probes are needed:
1. One general "track started commands"-probe (which tracks both
builtins and external commands)
2. One probe for external commands
3. One probe for builtin commands
This would allow a fine-grained way to track what''s going on in a
shell,
including hiccups caused by builtins. Or do some profiling external
commands vs. builtins...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

When you''re ready to try some probes, why not just pick the
simplest one you know how to do that would be useful,
implement that and demo it to the AT&T guys, and if they
like what it can do, brainstorm with them for what other
probes would be useful and not too hard to do.
 
 
This message posted from opensolaris.org

There is no need for advertising. The AT&T guys like the Dtrace probes idea.

Bruno

On 3/19/07, Richard L. Hamilton <rlhamil at smart.net>
wrote:
> When you''re ready to try some probes, why not just pick the
> simplest one you know how to do that would be useful,
> implement that and demo it to the AT&T guys, and if they
> like what it can do, brainstorm with them for what other
> probes would be useful and not too hard to do.
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>