support static binaries

[wangbj]

Currently we rely on LD_PRELOAD to load the --tool library, however, LD_PRELOAD doesn't work with static binaries, such as compiled go programs. It is possible to write our own mini (dynamic) loader, for static binaries only, though it wouldn't be trivial to write a dynamic loader.

[rrnewton]

When we do need to cross this bridge, is there any shortcut to take? Currently the --tool is provided only as a shared object, but perhaps there is some other format (maybe just a .o file?) that is easier to manually link in?

GHCI for a long time maintained their own loader... I can't recall if they ever successfully got rid of it.

Here's another dumb question... is there a reason you can't hackily invoke the normal dynamic linker via ptrace from inside the execution of a statically-binary guest?

[wangbj]

It might be possible, I haven't spend too much time thinking of it, but we might be able to hijack tracee's PC, then redirect it to do a dlopen, so we don't really to write our own loader. Will try this approach first.

[rrnewton]

Again, fine to push down the road for now ;-). But always ok to spend a 1-3 hours and just poke at it to probe how hard it will be.

[wangbj]

I didn't know GHC maintained their own loader, dlopen might not work, because it requires a symbol from ld-linux.so.

[wangbj]

likely we could try to write a static loader (way easier) to load ld-linux.so, and then ask ld-linux.so to load the tool library (by dlopen).

[wangbj]

The problem with is ld-linux.so doesn't seem export symbols to load other libraries, it has a function named _dl_open (not the same as dlopen, which is in libdl.so), but it is not exported and there's no easy/portable way to find it's address, symbol looking won't work either, because it is completely hidden.