Otherwise, we use the unrelocated virtual address, which points nowhere.

lookup() is too similar to symbol lookup

The 'program' object allows us to later resolve symbols (aka dlopen()/dlsym()).

No threading yet, so no real locking

Don't load it from the glibc library.

Weak symbols are allowed to fail name resolution, in which case they bind to
zero.

Some libraries come without DT_HASH.

We need to parse the core's dynamic segment, which is linked to from the
program header.  Since the core is not an elf_file, but an elf_object, we
need to move the parsing code there.

The dynamic linker itself needs to be linked before it can be used.  This
implements a minimal pre-linker that self-links the linker without invoking
anything that needs to be linked.

Not strictly needed, but better to know exacly where things end up.

This forces the linker to add a DYNAMIC segment, allowing us to export our
symbols to loaded libraries.

This gives us full control over linker options.

Not correct yet.

If .bss starts on a non-page boundary, the call to map_anon() will overwrite
the last .data page.

Fix by aligning the arguments to map_file() and map_anon() manually; this
removes the overlap (since we round the .data section up).

not accurately though.

libgcc_s uses that (likely because it makes no syscalls)

Ignored, unneeded.

Should we warn instead?

prelinked libraries default to a non-zero address; we have to take that
into account when computing the base.