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