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

Joerg Sonnenberger via cfe-dev cfe-dev at lists.llvm.org
Fri Dec 4 14:29:40 PST 2015

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:


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


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.


More information about the cfe-dev mailing list