Opened 4 years ago

Last modified 5 months ago

#3625 new bug

GHCI doesn't work with dtrace on OS X

Reported by: rl Owned by:
Priority: low Milestone: 7.6.2
Component: GHCi Version: 6.10.4
Keywords: Cc: pho@…, anton.nik@…, hvr
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:


On OS X, user-defined dtrace probes are implemented as special symbols of the form ___dtrace_probe$... which are magically resolved by the linker. In the attached package, we have this dtrace script:

provider haskell {
  probe demo__trace(char*);

and this C file:

void demo_trace( char *s )

When we compile it, we get:

newbie:dtrace-demo rl$ nm demo-trace.o
         U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
         U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
         U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace

When linked as a dynamic library, the undefined symbols disappear:

newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o 
newbie:dtrace-demo rl$ nm demo-trace.dylib 
00000000 t __mh_dylib_header
000008b0 T _demo_trace

But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, ghci -package dtrace-demo produces this error:

unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'

Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.

The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.

Attachments (1)

dtrace-demo-1.0.tar.gz (1.9 KB) - added by rl 4 years ago.

Download all attachments as: .zip

Change History (12)

Changed 4 years ago by rl

comment:1 Changed 4 years ago by duncan

dlopen() cannot load .o files, only .so / .dynlib files. As I understand it that's the reason for the ghci linker in the first place. The system linker is already used for the cases it can cope with.

Moving to building Haskell packages as shared libs would solve this problem for packages but not for .o files in the local build tree.

comment:2 Changed 4 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 6.14.1

comment:3 Changed 3 years ago by PHO

  • Cc pho@… added
  • Type of failure set to None/Unknown

comment:4 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:5 Changed 3 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:6 Changed 3 years ago by lelf

  • Cc anton.nik@… added

comment:7 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:8 Changed 2 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1
  • Priority changed from normal to low

comment:9 Changed 20 months ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:10 Changed 5 months ago by carter

  • Cc hvr added

is this resolved with ghc 7.7 head? Has anyone tested dtrce with head? if not i'll try to find the time to test it out soon.

comment:11 Changed 5 months ago by lelf

Betty:cbits lelf$ sudo dtrace -i 'demo-trace{printf("%s",copyinstr(arg0))}'
dtrace: description 'demo-trace' matched 1 probe
CPU     ID                    FUNCTION:NAME
  0   2547            demo_trace:demo-trace rzzzz
  1   2547            demo_trace:demo-trace foo
  0   2547            demo_trace:demo-trace bar
  0   2547            demo_trace:demo-trace bzzzzz

Seems to work

Note: See TracTickets for help on using tickets.