[cfe-dev] [llvm-dev] [RFC][ARM] Add support for embedded position-independent code (ROPI/RWPI)

[Joerg Sonnenberger via cfe-dev]

On Fri, Dec 04, 2015 at 05:45:01PM -0000, Oliver Stannard wrote:
> > 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.
> 
> This is only a problem when a const initialiser has to be is placed in
> a read-write section, as other translation units will access it
> incorrectly. I've added a warning when this happens.

Depends on how exactly your initialiser code works. I had assumed you
are going with a TLS-like model of init-on-first access, since you
didn't want to use a dynamic-linker like startup code...

> > 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.
> 
> That sounds like the same thing as options 2 and 3 above, right?
> I think the main difference in the embedded world is that code and RO
> data are stored in ROM or flash which are impossible or slow to
> overwrite, and minimising the amount of RAM used is desirable. Also,
> since this isn't being used for actual dynamic linking but just for a
> few static initialisers, the dynamic loader would be an unnecessary
> increase in code size.

Stop being hung-up on the term dynamic loader. Let's take a look at the
NetBSD implementation for ARM. The entry point of RTLD is _rtld_start:

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/libexec/ld.elf_so/arch/arm/rtld_start.S?rev=1.12

The important part here is the call to _rtld_relocate_nonplt_self, which
can be found in:

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/libexec/ld.elf_so/arch/arm/mdreloc.c?rev=1.38

That's all the code needed for rtld to be position independent. Your
embedded case is likely to be quite similar in complexity -- no
iteration over the ELF program header, but maybe more than one
relocation type (implicitly assumed). Over all, it should be much less
than 150 Bytes of code.

Joerg