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;)
