Loading package ghc within GHCi
Simon Marlow
simonmar at microsoft.com
Thu Jan 6 06:20:16 EST 2005
On 05 January 2005 22:20, Wolfgang Thaller wrote:
>> The "hook" idea works with static linking: the RTS provides a default
>> version of the hook, that can be overriden by a user-supplied
>> function of the same name. This is what GHC does. However, our
>> dynamic linker doesn't support this kind of overriding. The
>> system's dynamic linker does, though: that's why you can still
>> provide your own malloc() and functions in libc.so will use yours
>> rather than the default one.
>
> Note that the Darwin and (AFAIK) Windows dynamic linker do not support
> this behaviour. They explicitly avoid that kind of behaviour to
> prevent accidental overriding. (What happens on Linux if you link a
> GHC-compiled program to a shared library that internally uses a
> function named "allocate"? What if the next revision of that library
> introduces such a function?)
>
> What are the alternatives to using these hook functions? Explicitly
> looking for a OutOfHeapHook symbol in the executable using dlsym and
> friends? Exporting a "RegisterOutOfHeapCallback" function from the
> rts? Both seem a bit inconvenient to me, but some change might be
> necessary when we use dylibs/dlls.
I'm not a big fan of the overriding semantics either. The problem with
RegisterOutOfHeapCallback() is that you have to actually provide some
code that gets run to register the callback, which means you have to
provide your own main() (and therefore override the RTS-supplied main()
:-).
Can we use weak symbols for this? Are weak symbols widely-supported
enough?
Cheers,
Simon
More information about the Glasgow-haskell-users
mailing list