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
