dtrace discuss - Mar 2008 - Modifying macro names generated by dtrace -h

I''d like to prepend TRACE_ to the macro names generated by dtrace -h. 
For example, change
POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) to 
TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) and still keep postgresql as 
the provider name. The reason for doing this is to make it clear that 
the macros are used for (D)tracing. In this particular case, without 
TRACE_, it appears like the macro is used for acquiring locks.

I tested this out on both Solaris and Mac OS X Leopard, and it seems to 
work just fine. Is this safe to do? Any potential problems I''m not
aware of?

It would be nice if this can be done by specifying the prefix in the .d 
file or through the dtrace program.

Regards,
-Robert

On Mon, Mar 03, 2008 at 11:43:03AM -0600, Robert Lor
wrote:
> I''d like to prepend TRACE_ to the macro names generated by dtrace
-h.
> For example, change
> POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) to 
> TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) and still keep postgresql as 
> the provider name. The reason for doing this is to make it clear that 
> the macros are used for (D)tracing. In this particular case, without 
> TRACE_, it appears like the macro is used for acquiring locks.
> 
> I tested this out on both Solaris and Mac OS X Leopard, and it seems to 
> work just fine. Is this safe to do? Any potential problems I''m not
aware of?
> 
> It would be nice if this can be done by specifying the prefix in the .d 
> file or through the dtrace program.
> 
> Regards,
> -Robert
There''s nothing wrong with changing the macro names, and I agree
it''d be
nice to provide an option to set the prefix.  If anyone wants to take a
whack at a very simple extension to libdtrace this is a good one.
Basically just add a new -x option and make the dt_program.c code in
libdtrace look at it when generating the names and prepend that as well.

-Mike

-- 
Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/

Hi Robert,

This is exactly what I had in mind with the DTrace header generator script
I posted awhile ago:

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

The intended use is for developers to check this file into their own project
and make whatever modifications are necessary. At some point, I''d like
to put
this back to ON.

Adam

On Mon, Mar 03, 2008 at 11:43:03AM -0600, Robert Lor
wrote:
> I''d like to prepend TRACE_ to the macro names generated by dtrace
-h.
> For example, change
> POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) to 
> TRACE_POSTGRESQL_LWLOCK_ACQUIRE(arg0, arg1) and still keep postgresql as 
> the provider name. The reason for doing this is to make it clear that 
> the macros are used for (D)tracing. In this particular case, without 
> TRACE_, it appears like the macro is used for acquiring locks.
> 
> I tested this out on both Solaris and Mac OS X Leopard, and it seems to 
> work just fine. Is this safe to do? Any potential problems I''m not
aware of?
> 
> It would be nice if this can be done by specifying the prefix in the .d 
> file or through the dtrace program.
> 
> Regards,
> -Robert
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Mike Shapiro wrote:
> There''s nothing wrong with changing the macro names, and I agree
it''d be
> nice to provide an option to set the prefix.  If anyone wants to take a
> whack at a very simple extension to libdtrace this is a good one.
> Basically just add a new -x option and make the dt_program.c code in
> libdtrace look at it when generating the names and prepend that as well.
>   
Great. Should this be captured as an RFE?

Thanks,
-Robert

Adam Leventhal wrote:
> This is exactly what I had in mind with the DTrace header generator script
> I posted awhile ago:
>
>   http://www.opensolaris.org/jive/thread.jspa?messageID=132638
>
> The intended use is for developers to check this file into their own
project
> and make whatever modifications are necessary. At some point, I''d
like to put
> this back to ON.
>
>
>   
Thanks Adam. I think this script does what we need, but I need to find 
out that Perl is a required tool to build Postgres for all the supported 
platforms.

-Robert