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
_______________________________________________
dtrace-discuss mailing list
[email protected]
