[llvm-dev] [RFC][ARM] Add support for embedded position-independent code (ROPI/RWPI)
Joerg Sonnenberger via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 4 07:39:29 PST 2015
On Fri, Dec 04, 2015 at 01:46:13PM -0000, Oliver Stannard via llvm-dev wrote:
> In addition to passing the command-line options through to the backend,
> clang must be changed to work around a limitation in these modes: since
> there is no dynamic loader, if a variable is initialised to the address
> of a global value, it's initial value is not known at static link time.
> For example:
> extern int i;
> int *p = &a; // Initial value unknown at static link time
> SysV-style PIC solves this by having the dynamic linker fix up any
> relocations on the data segment. Since these modes are trying to avoid
> the need for a dynamic linker, we instead have the compiler emit code to
> initialise these variables at startup time. These initiailisers are
> expected to be rare, so the dynamic initiaslisers will be smaller than
> the equivalent dynamic linker plus relocation and symbol tables.
You don't need a full blown dynamic linker to handle that, just that the
linker creates output that can be appropiately references by the init
code. I don't think that dynamic initialisers will work correctly at
all, since you can access "i" in a separate module that doesn't know
about the initialiser at all.
Consider taking a look how most dynamic linkers operate themselve in the
ELF world. One of the first things they do is relocate themselve by
processing their own relocation table and applying the fixups. This
doesn't involve symbol tables at all, just patching up addresses.
As such, I don't think such transformation belongs into clang.
More information about the llvm-dev