Vtables not position independent for target thumbv7em-none-eabi

[torfmaster]

Summary

I'm having trouble using dynamic dispatch for trait objects on a cortex-m4.
The setup is rather complicated as relocated binaries only make sense for binaries which will actually be relocated. In this case I try to run a tock app created with libtock-rs.

The vtables in the binary get relocated, however the content of the vtables is not position independent but pointing to the load addresses of the function to be called.

I have written a "fixup-routine" in the following pull request, however uses a very rough heuristics to identify vtables in the .rodata section:
tock/libtock-rs#56

Description of the problem

I compile (using nightly-2018-08-16) the traitobj-Example in the PR using ropi-relocation model. Access to the vtable works just fine as the addresses of the vtables are access relatively to the position of the application in flash. However, the addresses in the vtables point to the static load address in the binary of the functions to call.

Currently, I solve the problem using a fixup routine which fixes the addresses in the vtables (and potentially destroys other elements of .rodata).

Expected behavior

The addresses in the vtables should be accessed in a way which is position independent.
At least there should be a way to identify vtables in the .rodata segment such that at least theoretically the vtables could be fixed. However, recently the behavior of the Rust compiler changed so that it creates vtable-Symbols which don't carry names containing "vtable" anymore so for me it is impossible to find these symbols ( rust nightly 2018-06-14 stil creates symbols named vtable).

Provide information

The description provided here is relatively rough. Please help me providing the information necessary to investigate the problem.

[nagisa]

Does the ropi-rwpi relocation model work?

[torfmaster]

If I understand right that ROPI makes the .rodata-section position independent, yes. However, we have a double indirection here: References contained in .rodata are not relocated. RWPI does not work, i.e. when used (by creating a static mut) the linker (rust-lld) refuses to link (unrecognized reloc).

[jrvanwhy]

I think this is a specific case of the larger issue of global references. LLVM ROPI-RWPI implementation does not support const global references. I'm taking a look at this now, but it lies far outside my area of expertise.

[lenary]

ARM had to make a lot of changes to Clang to ensure that ROPI/RWPI was supported (Patch attached to this mailing list message: https://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html)

Only a subset of these changes were merged. The merged changes just ensured the PIC information was correctly passed to LLVM. The unmerged changes all relate to how to do static initialisers correctly, including how to deal with the C/C++ equivalent of static mut. The message and the patch clarify what the problem is.