std library hooks

[Artur Skawina]

On 04/15/12 22:45, Nick Sabalausky wrote:
> Yea, I'm now more convinced than ever that proper hooks, or at least 
> something more formalized, would be a WAAAY better way to go. I mean, I can 
> see it's technically doable the current way, but it's basically voodoo hacks 
> and unhelpful error messages. And not even reliable across different 
> linkers, apperently.

The runtime as a shared lib would make things easier, btw.

Hooks would add overhead. If you want to selectively replace symbols
during the link phase, *some* linker awareness is necessary...
And some linkers will even help you do it; another ld example:
---------------------------------------------------------------------------------
// gdc -O3 -fdeprecated wrapgc.d -o wrapgc -Wl,--wrap=gc_malloc -Wl,--wrap=gc_qalloc

import std.stdio;
import core.sys.posix.stdlib;
import uni = core.sys.posix.unistd;
import core.memory;

extern (C) {
   void* __real_gc_malloc(size_t s, uint a);
   void* __wrap_gc_malloc(size_t s, uint a) {
      uni.write(2, "M".ptr, 1);
      return __real_gc_malloc(s, a);
   }
   BlkInfo_ __real_gc_qalloc(size_t s, uint a);
   BlkInfo_ __wrap_gc_qalloc(size_t s, uint a) {
      uni.write(2, "Q".ptr, 1);
      return __real_gc_qalloc(s, a);
   }
}

void  main(string[] argv) {
   string s1 = argv[0];
   s1 = "*" ~ s1;
   writeln(s1);
}
---------------------------------------------------------------------------------

Unlike a hook, this adds zero interception overhead and could be moved
into a linker script if you need to do this to a larger amount of symbols.

Having a well defined stable runtime binary interface would obviously help.

artur