[PATCH] D72959: Relative VTables ABI on Fuchsia

Thu Jan 23 03:29:39 PST 2020

peter.smith added a comment.

In D72959#1835368 <https://reviews.llvm.org/D72959#1835368>, @rjmccall wrote:

> There's two independently-useful things here for the relocation, right?  First, it's useful to be able to express a relocation to a symbol that has the semantics of a particular function but doesn't necessarily have its address, and that concept could be used across many "physical" relocations; and second, it's potentially useful to have a shifted-by-two relative address relocation, at least on AArch64 where instructions (and v-table entries under this ABI) are always four-byte-aligned anyway.  Is it possible to separate these concerns in ELF, e.g. by having a "symbol" that can be the target of any other relocation but which actually represents a function of unspecified address with the semantics of another function?

It would be possible to design relocations like that, but I think it would be difficult to fit into existing multi-target designs, which assume that the relocation code alone encodes all the actions a linker needs to take (smart-format, dumb-linker). My understanding of the reasons behind this are:

- The linker can have millions of relocations to resolve and  having all the actions explicit in the code simplifies its job.
- There is a large space of available relocation codes, partitioned per target, but a much more limited availability of target specific symbol types and flags.
- The concerns can be separated at implementation time, for example the symbol lookup, encoding and calculation stages are independent and shared between the codes.

It is possible that there is a better trade-off in complexity, but anything radically different might need quite a bit of work to fit into an existing linker. Hope I've understood you correctly and apologies if the above isn't relevant.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72959/new/

https://reviews.llvm.org/D72959