G Bulmer
2008-Mar-07 18:17 UTC
[dtrace-discuss] Help: problems building SDT''s for Erlang DTrace
Help
I have been working on inserting SDT''s into Erlang.
I am having several problems. I have just moved environments (see
Background) and this may be contributing to the problems.
I''m on Mac OS X 10.5.2, and I get a link time error from the Erlang
build (which has been okay for months).
When I make, the last command issues is:
gcc -o /Users/garrybulmer/Research/Erlang-DTrace/erl_dtrace/
otp_src_R12B-0/bin/i386-apple-darwin9.2.0/beam ...
error: Must have a valid dtrace stability entry
ld: error creating dtrace DOF section
...
I googled, and only found one reference in the Apples source at:
http://www.opensource.apple.com/darwinsource/Current/dtrace-48/libdtrace/dt_ld.m
in dtrace_ld_create_dof()
There is no other page found by google (a googlewhack, which isn''t
encouraging!)
Here''s the dtrace_probes.d file defining the probe interface:
provider erl__dtrace {
probe gc__begin();
probe gc__end();
probe gc__inp(int, char*);
probe gc__outp(int, char*);
probe dtrace(int); /* passes the Erlang Process ID */
probe dtrace__s(int, char*); /* passes Erlang PID and string */
};
#pragma D attributes Evolving/Evolving/Common provider erl__dtrace
provider
#pragma D attributes Private/Private/Unknown provider erl__dtrace module
#pragma D attributes Private/Private/Unknown provider erl__dtrace
function
#pragma D attributes Evolving/Evolving/Common provider erl__dtrace name
#pragma D attributes Evolving/Evolving/Common provider erl__dtrace args
----- end ----
I have looked through the forum, but I''ve failed to find the solution,
so HELP!
G Bulmer
Background:
My MacBook was running Tiger (my day job), so I was developing using
Leopard run on an external firewire hard drive. This worked okay.
Yesterday I upgraded my MacBook from Tiger to Leopard (ready for next
weeks DTrace un-conference), all of my problems have happened since
then in this new environment. I do not want to carry an external drive
with me, so I need to fix the MacBook.
The dtrace_probes.h file generated by "dtrace -h -s dtrace_probes.d"
looks okay (AFAIK):
/*
* Generated by dtrace(1M).
*/
#ifndef _DTRACE_PROBES_H
#define _DTRACE_PROBES_H
#include <unistd.h>
#ifdef __cplusplus
extern "C" {
#endif
#define ERL__DTRACE_STABILITY "___dtrace_stability$erl__dtrace
$v1$5_5_5_1_1_0_1_1_0_5_5_5_5_5_5"
#define ERL__DTRACE_TYPEDEFS "___dtrace_typedefs$erl__dtrace$v1"
#define ERL__DTRACE_DTRACE(arg0) \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$dtrace$v1$696e74(arg0); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_DTRACE_ENABLED() \
__dtrace_isenabled$erl__dtrace$dtrace$v1()
#define ERL__DTRACE_DTRACE_S(arg0, arg1) \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$dtrace__s$v1$696e74$63686172202a(arg0,
arg1); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_DTRACE_S_ENABLED() \
__dtrace_isenabled$erl__dtrace$dtrace__s$v1()
#define ERL__DTRACE_GC_BEGIN() \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$gc__begin$v1(); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_GC_BEGIN_ENABLED() \
__dtrace_isenabled$erl__dtrace$gc__begin$v1()
#define ERL__DTRACE_GC_END() \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$gc__end$v1(); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_GC_END_ENABLED() \
__dtrace_isenabled$erl__dtrace$gc__end$v1()
#define ERL__DTRACE_GC_INP(arg0, arg1) \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$gc__inp$v1$696e74$63686172202a(arg0,
arg1); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_GC_INP_ENABLED() \
__dtrace_isenabled$erl__dtrace$gc__inp$v1()
#define ERL__DTRACE_GC_OUTP(arg0, arg1) \
{ \
__asm__ volatile(".reference " ERL__DTRACE_TYPEDEFS); \
__dtrace_probe$erl__dtrace$gc__outp$v1$696e74$63686172202a(arg0,
arg1); \
__asm__ volatile(".reference " ERL__DTRACE_STABILITY); \
}
#define ERL__DTRACE_GC_OUTP_ENABLED() \
__dtrace_isenabled$erl__dtrace$gc__outp$v1()
extern void __dtrace_probe$erl__dtrace$dtrace$v1$696e74(int);
extern int __dtrace_isenabled$erl__dtrace$dtrace$v1(void);
extern void __dtrace_probe$erl__dtrace$dtrace__s
$v1$696e74$63686172202a(int, char *);
extern int __dtrace_isenabled$erl__dtrace$dtrace__s$v1(void);
extern void __dtrace_probe$erl__dtrace$gc__begin$v1(void);
extern int __dtrace_isenabled$erl__dtrace$gc__begin$v1(void);
extern void __dtrace_probe$erl__dtrace$gc__end$v1(void);
extern int __dtrace_isenabled$erl__dtrace$gc__end$v1(void);
extern void __dtrace_probe$erl__dtrace$gc__inp
$v1$696e74$63686172202a(int, char *);
extern int __dtrace_isenabled$erl__dtrace$gc__inp$v1(void);
extern void __dtrace_probe$erl__dtrace$gc__outp
$v1$696e74$63686172202a(int, char *);
extern int __dtrace_isenabled$erl__dtrace$gc__outp$v1(void);
#ifdef __cplusplus
}
#endif
#endif /* _DTRACE_PROBES_H */
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080307/f74ecd73/attachment.html>
James McIlree
2008-Mar-07 19:13 UTC
[dtrace-discuss] Help: problems building SDT''s for Erlang DTrace
On Mar 7, 2008, at 10:17 AM, G Bulmer wrote:> Help > > I have been working on inserting SDT''s into Erlang. > I am having several problems. I have just moved environments (see > Background) and this may be contributing to the problems. > > I''m on Mac OS X 10.5.2, and I get a link time error from the Erlang > build (which has been okay for months). > > When I make, the last command issues is: > gcc -o /Users/garrybulmer/Research/Erlang-DTrace/erl_dtrace/ > otp_src_R12B-0/bin/i386-apple-darwin9.2.0/beam ... > > error: Must have a valid dtrace stability entry > ld: error creating dtrace DOF section > ... > > I googled, and only found one reference in the Apples source at: > http://www.opensource.apple.com/darwinsource/Current/dtrace-48/libdtrace/dt_ld.m > in dtrace_ld_create_dof() > There is no other page found by google (a googlewhack, which isn''t > encouraging!) > > Here''s the dtrace_probes.d file defining the probe interface: > provider erl__dtrace { > probe gc__begin(); > probe gc__end(); > probe gc__inp(int, char*); > probe gc__outp(int, char*); > > probe dtrace(int); /* passes the Erlang Process ID */ > probe dtrace__s(int, char*); /* passes Erlang PID and string */ > }; > > > #pragma D attributes Evolving/Evolving/Common provider erl__dtrace > provider > #pragma D attributes Private/Private/Unknown provider erl__dtrace > module > #pragma D attributes Private/Private/Unknown provider erl__dtrace > function > #pragma D attributes Evolving/Evolving/Common provider erl__dtrace > name > #pragma D attributes Evolving/Evolving/Common provider erl__dtrace > args > ----- end ---- > > > I have looked through the forum, but I''ve failed to find the > solution, so HELP! > > G Bulmer > > > Background: > My MacBook was running Tiger (my day job), so I was developing using > Leopard run on an external firewire hard drive. This worked okay. > Yesterday I upgraded my MacBook from Tiger to Leopard (ready for > next weeks DTrace un-conference), all of my problems have happened > since then in this new environment. I do not want to carry an > external drive with me, so I need to fix the MacBook.The good news is that if this was working before, its likely to be something fixable thats making it not work now. The bad news is it may be a bit difficult to track down :-). The only way you''ll get the error above is if the linker cannot find stability info in your .o''s. You can check to see if the info is really there by running nm on the .o''s and grep''ing for "dtrace_stability". If you see something like this: ghopper:~> nm testStabilityEncoding.o | grep dtrace_stability U ___dtrace_stability$poly$v1$1_1_0_1_1_0_1_1_0_1_1_0_5_5_5 U ___dtrace_stability$polyA$v1$1_1_0_1_1_0_1_1_0_1_1_0_5_5_5 That means you''ve got valid stability encoding available and you''ve found a real bug. Assuming you don''t find entries, why wouldn''t they be there? The most common case is using ENABLED() tests without actually calling a probe. If you aren''t calling the probes, the stability info isn''t encoded and you can end up with this error. Any probe call anywhere will do, you can put it in out of line code kept in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ?Beware of The Leopard?. If thats not the problem, or you find that you''ve got valid stability info but still cannot get things to link, contact me directly and we''ll figure out what is going wrong offline. James M