Instead of LD_PRELOAD, use a custom dynamic linker

[stephenrkell]

To insert liballocs into the process, we use LD_PRELOAD. But even better would be a custom dynamic linker, since we would get control at the very beginning. This could simplify our initialization logic, e.g. avoiding our need to special-case "internal" malloc calls occurring during dlopen or lazy symbol resolution.

I have been working on making it easy to build custom dynamic linkers, in my libgerald project. So the idea is to use and extend that, to create an allocsld.so, which would then be the natural choice of interpreter for binaries generated using our compiler wrapper, linker plugin etc.. It should be possible to invoke this linker as a command (allocsld.so /path/to/binary) for binaries not built with our toolchain extensions.

[stephenrkell]

Following the fix of #47 we're part of the way there: we have a custom loader. It doesn't do very much, though.

I'm debating whether we should abandon link-time instrumentation, and just instrument callees using raw surgery. That would keep things cleaner, but would waste memory in a whole-system context. (... unless/until we have a persistent code cache for the instrumented binaries, but that itself is a hack.)