~/.local/share/Steam/ubuntu12_32/steam has a symbol with a weird
binding type part way through its symbol table:

46 [OBJECT   LOOS/GNU_UNIQUE] size: 0 (0)_ZNSs4_Rep20_S_empty_rep_storageE 0000 (nil)

but we can't just stop there, because there are symbols after it that
need relocating.

I blame C++.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

The first few (which happen to be the ones we implement) happen to
be in obviously corresponding pairs between i386 and x86_64, but
after that they diverge.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This list is correct as of glibc 2.24.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Conflicts:
	utils/process-pt-dynamic.c

This information is not available in te SDL/dlopen use pattern
so we can't reliably check it.

The type-safety isn't particularly important, but the types make them
more self-documenting.

Signed-off-by: Simon McVittie <smcv@collabora.com>

The base address is a perfectly valid address, which we could
dereference if we wanted to, so it should be a pointer. The start of
the PT_DYNAMIC program header isn't an address (it's relative to base)
so make it a mere integer.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Now that we do this in two passes, if we haven't found a valid
DT_PLTRELSZ, DT_PLTREL or DT_RELASZ yet, we never will.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

base is a valid pointer into memory, whereas start is only an offset
and so is not a pointer that we can dereference. Previously, base was
a pointer-sized integer and start was a pointer, which is exactly
backwards if we want to stick to a rule of "it's a pointer iff
you could dereference it".

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

We relocate DT_REL entries in a DT_JMPREL section, and DT_RELA entries
either in a DT_JMPREL or DT_RELA section, so for symmetry it seems
like we should maybe be willing to relocate DT_REL entries in a
DT_REL section? For now, log it so we know whether it even happens.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

In the first pass, we record the information we'll need in the second
pass. In the second pass, we do the actual work.

In particular this appears to fix a crash I was seeing with OpenArena
on a Debian 9 runtime on a Debian 8-based host, where the symbol
table appeared to be NULL - it looks as though that was crashing
because for that particular library, the DT_SYMTAB happened to appear
later in the dynamic section entry array than the DT_RELA or DT_JMPREL.

This should also let us stop using find_value(), but I haven't tried
that yet.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Extra debug for success/failure/noop cases.

Move some of the deeper detail into the ELF class rather than
RELOC to reduce noise now that we're out of early alpha status.

Some ElfW(Rel[a]) d_ptr items are pre-calculated form base, others not.

This has the advantage that out-of-tree code and in-tree code can
both include the header the same way.

Signed-off-by: Simon McVittie <smcv@collabora.com>

The removal of the addr() address/base fixup logic aldo turns out
to have been premature, so restored for the find_ptr() helper.

Yubin Ruan <ablacktshirt@gmail.com> spotted that I was conflating
the base-relative address offset in ElfW(Rel) and ElfW(Rela) addresses
from DT_REL and DT_RELA sections with the absolute addresses from
ElfW(Dyn) pointer entries.

This fixes a long-standing TODO about removing the hack in addr()
where there was guesswork about whether the address being was
base-relative or absolute.

Although we do not encounter DT_REL entries on x86_64 the handling
is currently identical for all relocation types so far encountered.

Keep the handling in sync as this will matter more on arches (i386?)
where we actually get DT_REL entries.

warning: signed and unsigned type in conditional expression [-Wsign-compare]

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

R_X86_64_GLOB_DAT and R_X86_64_64 are now supported.

When munging the ELF data structures from the capsule-export code path
via dl_iterate_phdr, we get the dynamic section size as a callback arg
so we can double-check we haven't ended up outside the memory region
we expect to be working on.

Unfortunately when using link_map traversal to do the same sort of thing
to install wrapper functions inside the capsule we don't have this
information. We were using SIZE_MAX on ELFCLASS64 to pass a "big enough"
size parameter but this calculation does not work on ELFCLASS32.

Rather than go out of our way to produce a bogus-but-big-enough value
we now pass 0 for the size and have the called functions know that they
can't do the double-check if passed a size of 0.

The last entry in the dyn section should have a D_TAG of DT_NULL
anyway so we'll only crash off the end of the dynamic section if
the linker is broken or malicious (which is probably not worth
defending against, all things considered).

Define and use some per-word-size printf format macros so our
debug functions can be -Wall -Werror clean on both models.

The r_addend member is ElfW(Sxword) in 64 bit ELF but ElfW(Sword)
in 32 bit mode. This mostly doesn't matter but if we want to quash
a pointer/integer size-mismatch warning we need to have a different
protoype for the address offset calculator helper in each model.

If we use the ELF64 and ELF32 _R_x macros in the relevant branches of
a switch( __ELF_NATIVE_CLASS ) case statement we're guaranteed to be
safe but the compiler isn't smart enough to deduce this and emits some
warnings about bit shift overflows.

Use #if __ELF_NATIVE_CLASS == x code selection instead.