dtrace discuss - Jan 2008 - dtrace -h -s myprobes.d resulting header file has surprises

Running dtrace -h -q myprobes.d, where myprobes.d contains the following:

provider myprobes {
probe mystuff__enter(int, int);
probe mystuff__return(int, int);
};

results in a header file that has the proper macro defines. However the double
underscores are changed into single underscores. This while the convention is to
replace a double underscore with a hyphen in the final probe name.

Is this an oversight?  Or intentionally? 

I would like to use those reasonably named macro''s in my source code,
however since using the hyphen lots of time to create a distinction and enhance
readability I really do not like this behaviour of exchanging double underscores
with a single one.

--Paul



/*
 * Generated by dtrace(1M).
 */
 
#ifndef _MYPROBES_H
#define _MYPROBES_H

#include <unistd.h>

#ifdef  __cplusplus
extern "C" {
#endif

#if _DTRACE_VERSION

#define MYPROBES_MYSTUFF_ENTER(arg0, arg1) \
        __dtrace_myprobes___mystuff__enter(arg0, arg1)
#define MYPROBES_MYSTUFF_ENTER_ENABLED() \
        __dtraceenabled_myprobes___mystuff__enter()
#define MYPROBES_MYSTUFF_RETURN(arg0, arg1) \
        __dtrace_myprobes___mystuff__return(arg0, arg1)
#define MYPROBES_MYSTUFF_RETURN_ENABLED() \
        __dtraceenabled_myprobes___mystuff__return()


exzxtern void __dtrace_myprobes___mystuff__enter(int, int);
extern int __dtraceenabled_myprobes___mystuff__enter(void);
extern void __dtrace_myprobes___mystuff__return(int, int);
extern int __dtraceenabled_myprobes___mystuff__return(void);

#else

#define MYPROBES_MYSTUFF_ENTER(arg0, arg1)
#define MYPROBES_MYSTUFF_ENTER_ENABLED() (0)
#define MYPROBES_MYSTUFF_RETURN(arg0, arg1)
#define MYPROBES_MYSTUFF_RETURN_ENABLED() (0)

#endif


#ifdef  __cplusplus
}
#endif

#endif  /* _MYPROBES_H */


--
This message posted from opensolaris.org

On Jan 31, 2008, at 12:07 PM, Paul van den Bogaard wrote:
> Running dtrace -h -q myprobes.d, where myprobes.d contains the  
> following:
>
> provider myprobes {
> probe mystuff__enter(int, int);
> probe mystuff__return(int, int);
> };
>
> results in a header file that has the proper macro defines. However  
> the double underscores are changed into single underscores. This  
> while the convention is to replace a double underscore with a hyphen  
> in the final probe name.
>
> Is this an oversight?  Or intentionally?
>
If you look at the macro definition the hyphen is preserved in the  
final probe name, but you don''t have to use the double underscore in  
the macro (just try to list the probes when your program is running).
>
> #define MYPROBES_MYSTUFF_ENTER(arg0, arg1) \
>        __dtrace_myprobes___mystuff__enter(arg0, arg1)
The double underscore is preserved


Trond

On Thu, Jan 31, 2008 at 03:07:20AM -0800, Paul van den Bogaard
wrote:
> results in a header file that has the proper macro defines. However
> the double underscores are changed into single underscores. This while
> the convention is to replace a double underscore with a hyphen in the
> final probe name.
> 
> Is this an oversight?  Or intentionally? 
This is intentional. I went back and forth on this a bit when implementing
the header file generation in dtrace(1M) and decided that the double
underscores looked stupid in the macros, and that I preferred non-stupid
looking code to the potential for conflicts (given that __ and _ would both
map to _) and confusion.
> I would like to use those reasonably named macro''s in my source
code,
> however since using the hyphen lots of time to create a distinction and
> enhance readability I really do not like this behaviour of exchanging
> double underscores with a single one.
It was a conscious decision. Apologies for the inconvenience, but it would
be tricky to change at this point.

Adam

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Adam,

again our views are different. Must be our heritage ;^)

Why was this header file creation invented given that the manual, in the chapter
of statically defined probes for applications, only mentions the
macro''s DTRACE_PROBExxx?

I have the impression that the "misunderstanding" starts with allowing
the hyphen in probe names: are there any other programming or scripting
languages that allow a math symbol in a variable name? But ala that decision has
been made.

"It would be tricky to..." is your final remark. Could you elaborate a
little here, since the core part of the code is working as Trond also pointed
out. It is just the "religions" "One underscore looks better in
macros" vs "Do not translate in an irreversable way"
My first hunch would be the following:

by default stick to the current behaviour. I that irreversable way is not wanted
use an option (yet another one) with dtrace  that "just" translates
the macro names keeping double underscores in place.

Am I missing something?

Thanks
Paul


--
This message posted from opensolaris.org

On Fri, Feb 01, 2008 at 12:11:52AM -0800, Paul van den Bogaard
wrote:
> Why was this header file creation invented given that the manual, in
> the chapter of statically defined probes for applications, only
> mentions the macro''s DTRACE_PROBExxx?
The header file generation was developed both to support is-enabled probes,
and to add a better interface. The Solaris Dynamic Tracing Guide will be
updated when I get a chance. If anyone would like to take a whack,
here''s
the link to the wiki; send out a draft:

http://wikis.sun.com/display/DTrace/Statically+Defined+Tracing+for+User+Applications
> I have the impression that the "misunderstanding" starts with
> allowing the hyphen in probe names: are there any other programming or
> scripting languages that allow a math symbol in a variable name? But
> ala that decision has been made.
Many would consider the hyphen to be more typographical than mathematical,
but I don''t know whether other langages alow that as part of a lexical
object.
> "It would be tricky to..." is your final remark. Could you
elaborate
> a little here, since the core part of the code is working as Trond also
> p ointed out. It is just the "religions" "One underscore
looks better in
> macros" vs "Do not translate in an irreversable way"
It would be tricky by which I mean to say impossible to change by default as
that would break existing consumers.
> by default stick to the current behaviour. I that irreversable way is
> not wanted use an option (yet another one) with dtrace  that
"just"
> translates the macro names keeping double underscores in place.
One could add such an option to dtrace(1M), sure. I''m not sure it would
represent a real improvement and might be confusing to add another way to
do the same thing.

You could probably hack up my old dheadgen.pl to do what you want.

  http://www.opensolaris.org/jive/thread.jspa?messageID=132638&#132638

- ahl

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

reading the line

        $probename =~ s/__/_/g;

in dheadgen.pl it looks like  the hack is "simple". 

Is this perl script part of the distribution or a prototype?


--
This message posted from opensolaris.org

On Fri, Feb 01, 2008 at 01:08:06AM -0800, Paul van den Bogaard
wrote:
> reading the line
> 
>         $probename =~ s/__/_/g;
> 
> in dheadgen.pl it looks like  the hack is "simple". 
> 
> Is this perl script part of the distribution or a prototype?
It''s a prototype, but something I''ve been wanting to putback
to ON as a tool
for USDT developers to include in their source repositories.

Adam

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl