Support acting as startup code of a dynamic linker

[bjorn3]

Previously this would result in the relocation code using the wrong offset as AT_PHDR points to the program headers of the main executable rather than of the dynamic linker itself.

[sunfishcode]

I've not finished reviewing the relocation logic, but here's an initial few comments:

[sunfishcode]

As far as I can tell, this case 3 doesn't need the AT_BASE value; is that correct?

[bjorn3]

It's presence is used to check that we are case 3. The actual value is not used by case 3.

[sunfishcode]

I've thought about something like this too, however I think it's actually better if we don't have to do this. If it's dangerous for this code at the end of relocate to mix with our relocation code, that suggests our relocation code itself is dangerous.

So instead, we use inline asm to do the actual relocation loads and stores, which hides the crucial part which Rust can't think about from Rust, and it should also have the effect of obliging the optimizer to preserve the ordering of the relocations with other code.

[bjorn3]

The inline asm doesn't prevent moving a (speculative) load of a static that needs relocations to before the inline asm as the compiler assumes that relocations have already happened and loading a static doesn't have any side effects. Musl does this kind of fence between every relocation step (after R_RELATIVE relocation resolving (_dlstart_c -> __dls2), after setting the thread pointer (__dls2b -> __dls3) and finally after symbol relocations resolving and right before calling the entry point of the main program (__dls3 -> AT_ENTRY).

[sunfishcode]

I guess on a practical level, you're right that a black_box would avoid some obscure possibilities, though not all. I'd accept a PR for it.

On a theoretical level though, Rust doesn't make the kinds of guarantees that this code ultimately needs, and black_box, function pointers, volatile, asm! barriers, etc. aren't enough. We'd need guarantees like:

• "The compiler shall not codegen certain language constructs into calls
  to other crates, such as translating x == null() to x.is_null().
• "The compiler shall not codegen certain language constructs using uses
  of static data."

Rust doesn't make these kinds of guarantees. C doesn't either, even with optimization barriers. My best idea right now for making this code theoretically sound is to precompile relocate, hand-verify it, and embed it with include_bytes in the _start code so that it runs before any Rust code runs.

[bjorn3]

I can't get LLVM to produce a R_386_PC32 _DYNAMIC relocation for i686. 1: add dword ptr [esp], _DYNAMIC-1b is accepted by GCC, but not by LLVM. Clang complains with "cannot use more than one symbol in memory operand" and rustc produces a useless error message.

[bjorn3]

I've disabled it on x86 for now. It also seems that the relocation code is never needed on x86 anyway for any of the other tests. Either there is a dynamic linker to do relocations or the executable is a statically linked executable. It is never a static PIE binary.

[bjorn3]

CI should pass now.

[bjorn3]

Rebased

[sunfishcode]

Overall this looks good; just one more logic simplification that I think we can do:

[bjorn3]

Applied the simplification.

[sunfishcode]

Thanks!

[sunfishcode]

This is now released in origin 0.18.1.