I''m hoping to get a confirmation on the rationale as to why D has no
flow control statement:
As I see it, there have to be at least two reasons:
1) Loops would require backward branches, which are not allowed in DIF.
2) Loops and if/then/elses could violate the requirement for each probe
clause and corresponding ECB to have a fixed length trace record.
Have I got this right or wrong? Any other reasons?
Also, a side question: since the following seems to work:
BEGIN
{
x = 1000;
exit(0);
}
END
{
printf("%*d", x, 3);
}
I''m assuming that the printf action only places the variables in the
buffer, and that the output and gets formatted in post-processing after
the data is pulled out of the buffer by the consumer?
Thanks,
Chip
On Mon, Aug 21, 2006 at 02:13:58PM -0500, Chip Bennett wrote:> I''m hoping to get a confirmation on the rationale as to why D has no > flow control statement: > > As I see it, there have to be at least two reasons: > > 1) Loops would require backward branches, which are not allowed in DIF.Yep. This is a safety issue.> 2) Loops and if/then/elses could violate the requirement for each probe > clause and corresponding ECB to have a fixed length trace record.Yep, again. This is more of an implementation issue, but having ECB''s have varying length records is (at this point, anyway) a galactic mess -- especially since we use the fact that we know that an ECB''s size to perform static analysis for things like dynamic variable sizing.> Have I got this right or wrong? Any other reasons? > > Also, a side question: since the following seems to work: > > BEGIN > { > x = 1000; > exit(0); > } > END > { > printf("%*d", x, 3); > } > > I''m assuming that the printf action only places the variables in the > buffer, and that the output and gets formatted in post-processing after > the data is pulled out of the buffer by the consumer?That''s right. This isn''t a safety issue because it happens at user-level, not in probe context. - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Bryan Cantrill wrote:> especially since we use the fact that we know that an ECB''s size to > perform static analysis for things like dynamic variable sizing.OK, I don''t understand what you mean. Can you give me an example? Thanks, Chip
On Mon, Aug 21, 2006 at 02:42:47PM -0500, Chip Bennett wrote:> Bryan Cantrill wrote: > >especially since we use the fact that we know that an ECB''s size to > >perform static analysis for things like dynamic variable sizing. > OK, I don''t understand what you mean. Can you give me an example?We''re venturing into a dark part of the DTrace guts here, but take a look at the "DTrace Dynamic Variables" block comment in dtrace_impl.h, and give a close read to the paragraph that begins with "We observe that allocating new dynamic storage is tricky only because the size can vary..." - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Bryan Cantrill wrote:> On Mon, Aug 21, 2006 at 02:42:47PM -0500, Chip Bennett wrote: > >> Bryan Cantrill wrote: >> >>> especially since we use the fact that we know that an ECB''s size to >>> perform static analysis for things like dynamic variable sizing. >>> >> OK, I don''t understand what you mean. Can you give me an example? >> > > We''re venturing into a dark part of the DTrace guts here, but take a > look at the "DTrace Dynamic Variables" block comment in dtrace_impl.h, > and give a close read to the paragraph that begins with "We observe > that allocating new dynamic storage is tricky only because the size can > vary..." >I read through it a couple of times, and it''s going to take more thought. I''ll look at again when my interest is more than passing, and I''m not a on a deadline. Suffice it to say, however, I understand why you didn''t want to try to explain it here. :-) Thanks for the confirmation on the other items. Let me say too, something that I''ve noted before, but never had a good opportunity to bring up. Nice job on the code documentation. Chip> - Bryan > > -------------------------------------------------------------------------- > Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc >