dtrace discuss - Aug 2007 - sh DTrace provider available

As noted on my blog and at 
http://www.opensolaris.org/os/community/dtrace/shells/ I''ve made 
available a DTrace provider for the Bourne shell. Before anyone starts 
yelling at me for not starting with another shell, read the blog I made 
explaining why we started with shell (link on the community page 
referenced above).

For /bin/sh, I''ve put up something akin to a chapter in "the
book" on
how to use it, a copy of the x86 version of the shell built around 
nv70ish and the diffs.

I''d love for folks to have a play with it and give me feedback.

Brendan has also written some cool stuff on his blog about his playing 
with it (link in the above url).

We''re considering other shells too, just not done them yet.

Regards,
Alan Hargreaves

-- 
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Systems Technical Support Centre
Sun Microsystems

This is really neat!

Would it make sense to have probes on glob expansion, variable
substitution, etc...?

Nico
--

Hey Alan,

This is great stuff; just a couple of comments:

What would you think about command-entry/return rather than exec-entry/return?
Have you thought about building a ustack() helper or annotater?

Adam

On Tue, Aug 14, 2007 at 05:34:47PM +1000, Alan Hargreaves
wrote:
> As noted on my blog and at 
> http://www.opensolaris.org/os/community/dtrace/shells/ I''ve made 
> available a DTrace provider for the Bourne shell. Before anyone starts 
> yelling at me for not starting with another shell, read the blog I made 
> explaining why we started with shell (link on the community page 
> referenced above).
> 
> For /bin/sh, I''ve put up something akin to a chapter in "the
book" on
> how to use it, a copy of the x86 version of the shell built around 
> nv70ish and the diffs.
> 
> I''d love for folks to have a play with it and give me feedback.
> 
> Brendan has also written some cool stuff on his blog about his playing 
> with it (link in the above url).
> 
> We''re considering other shells too, just not done them yet.
> 
> Regards,
> Alan Hargreaves
> 
> -- 
> Alan Hargreaves - http://blogs.sun.com/tpenta
> Staff Engineer (Kernel/VOSJEC/Performance)
> Systems Technical Support Centre
> Sun Microsystems
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

G''Day Alan,

Here is the latest suggested master-list of probe names,

	builtin-entry
	builtin-return
	command-entry
	command-return
	function-entry
	function-return
	line
	script-start
	script-done

Fortunately it is an easy change (but a bit annoying to regenerate the
binary, patch and docs - sorry. :)

Other shell providers can follow suit.

Brendan


On Tue, Aug 14, 2007 at 08:15:56AM -0700, Adam Leventhal
wrote:
> Hey Alan,
> 
> This is great stuff; just a couple of comments:
> 
> What would you think about command-entry/return rather than
exec-entry/return?
> Have you thought about building a ustack() helper or annotater?
> 
> Adam
> 
> On Tue, Aug 14, 2007 at 05:34:47PM +1000, Alan Hargreaves wrote:
> > As noted on my blog and at 
> > http://www.opensolaris.org/os/community/dtrace/shells/ I''ve
made
> > available a DTrace provider for the Bourne shell. Before anyone starts
> > yelling at me for not starting with another shell, read the blog I
made
> > explaining why we started with shell (link on the community page 
> > referenced above).
> > 
> > For /bin/sh, I''ve put up something akin to a chapter in
"the book" on
> > how to use it, a copy of the x86 version of the shell built around 
> > nv70ish and the diffs.
> > 
> > I''d love for folks to have a play with it and give me
feedback.
> > 
> > Brendan has also written some cool stuff on his blog about his playing
> > with it (link in the above url).
> > 
> > We''re considering other shells too, just not done them yet.
> > 
> > Regards,
> > Alan Hargreaves
> > 
> > -- 
> > Alan Hargreaves - http://blogs.sun.com/tpenta
> > Staff Engineer (Kernel/VOSJEC/Performance)
> > Systems Technical Support Centre
> > Sun Microsystems
> > 
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
> 
> -- 
> Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Brendan
[CA, USA]

On Tue, Aug 14, 2007 at 10:37:23AM -0700, Brendan Gregg - Sun Microsystems
wrote:
> G''Day Alan,
> 
> Here is the latest suggested master-list of probe names,
> 
> 	builtin-entry
> 	builtin-return
> 	command-entry
> 	command-return
> 	function-entry
> 	function-return
> 	line
> 	script-start
> 	script-done
Sorry, I missed including,

	subshell-entry
	subshell-return

Now that''s the master-list (so far ;)

Brendan

-- 
Brendan
[CA, USA]

On Tue, Aug 14, 2007 at 10:41:26AM -0700, Brendan Gregg - Sun Microsystems
wrote:
> 	subshell-entry
> 	subshell-return
Speaking of which, a probe argument with process group ID and, for
shells with job control (i.e., not /bin/sh :), job number, would be
nice.

I guess I/O redirection probes would be nice as well.  And probes for
variable setting, interpolation/substitution, glob expansion...

Am I volunteering?  Hmmm, no, probably not :(

Nico
--

Alan Hargreaves wrote:
> Before anyone starts 
> yelling at me for not starting with another shell, read the blog I made 
> explaining why we started with shell (link on the community page 
> referenced above).
(The need for the disclaimer is maddening and disheartening at the same time.)

neet, Alan, and immediately widely useful (unlike anything for zsh or tcsh 
or ksh93 or MyShellBecauseI''mSoEclectic).

G''Day Nico,

On Tue, Aug 14, 2007 at 01:33:36PM -0500, Nicolas Williams
wrote:
> On Tue, Aug 14, 2007 at 10:41:26AM -0700, Brendan Gregg - Sun Microsystems
wrote:
> > 	subshell-entry
> > 	subshell-return
> 
> Speaking of which, a probe argument with process group ID and, for
> shells with job control (i.e., not /bin/sh :), job number, would be
> nice.
> 
> I guess I/O redirection probes would be nice as well.  And probes for
> variable setting, interpolation/substitution, glob expansion...
It takes time to plan how best to expose these in a stable and consistant
way. So far we''ve taken inspiration from the JavaScript and Ruby
providers,
but to delve deeper into the shells will take some time. Most of the time
developing the JavaScript provider wasn''t the code - it was planning
what
best to commit to.

For that reason, I think the priority would be to get the existing set
of probes into all the shells first, maybe with some additions if they
are obvious to commit to. Then, we''ll see what makes sense for version
2.
Your suggestions look like a good start.

I should note that I''ve been through this process for the JavaScript 
provider, which is at version 2 (and I''m thinking of what should be in
version 3). So when I say version 2, I don''t mean
won''t-be-done,
I mean version 2. :-)

... In testing the sh provider on real world scripts, I''ve already run
into a case where probing glob expansion time would be quite useful (as
it caused disk I/O and a significant latency).

cheers,

Brendan

-- 
Brendan
[CA, USA]

On Tue, 14 Aug 2007, Alan Hargreaves wrote:

> I''d love for folks to have a play with it and give me feedback.
>
I love it.  First, adding an example of fishing out argv[1] (i.e. arg4 of 
command-entry for example) might be really useful for others, it took me a 
bit to figure it out.

Second, one thing I''ve noticed is that if you do a source,
the filename inside the source is the outer filename, not the inner
filename.

# cat fileA
#!/bin/sh

. /tmp/fileB

# cat fileB

echo "Hi There from File B"

#

  sec-v20z-1 96 =>dtrace -n ''sh*:::builtin-entry{printf("%s
%d",
stringof(copyinstr(arg0)), arg2)}''
dtrace: description ''sh*:::builtin-entry'' matched 3 probes
CPU     ID                    FUNCTION:NAME
   0  81334            execute:builtin-entry ./fileA 3
   0  81334            execute:builtin-entry ./fileA 2

Is this the intended behavior? I suppose I could stash the filename on 
builtin-entry of ".", and fish it back out later, but that seems
counter
intuitive.

-- Dave