]> granicus.if.org Git - clang/commit
[ARM] Command-line options for embedded position-independent code
authorOliver Stannard <oliver.stannard@arm.com>
Mon, 8 Aug 2016 15:28:40 +0000 (15:28 +0000)
committerOliver Stannard <oliver.stannard@arm.com>
Mon, 8 Aug 2016 15:28:40 +0000 (15:28 +0000)
commit9acb854cc5ccfbef119542cb22ba05bbbf73e9c0
treef4c18ca9cedf126dd5b1fceefbcfa30d72fc959c
parentf12ee3b7751a95a6796e65eee39cb8e9ae4b3480
[ARM] Command-line options for embedded position-independent code

This patch (with the corresponding ARM backend patch) adds support for
some new relocation models:

* Read-only position independence (ROPI): Code and read-only data is accessed
  PC-relative. The offsets between all code and RO data sections are known at
  static link time.
* Read-write position independence (RWPI): Read-write data is accessed relative
  to a static base register. The offsets between all writeable data sections
  are known at static link time.

These two modes are independent (they specify how different objects
should be addressed), so they can be used individually or together.

These modes are intended for bare-metal systems or systems with small
real-time operating systems. They are designed to avoid the need for a
dynamic linker, the only initialisation required is setting the static
base register to an appropriate value for RWPI code.

There is one C construct not currently supported by these modes: global
variables initialised to the address of another global variable or
function, where that address is not known at static-link time. There are
a few possible ways to solve this:

* Disallow this, and require the user to write their own initialisation
  function if they need variables like this.
* Emit dynamic initialisers for these variables in the compiler, called from
  the .init_array section (as is currently done for C++ dynamic initialisers).
  We have a patch to do this, described in my original RFC email
  (http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html), but the
  feedback from that RFC thread was that this is not something that belongs in
  clang.
* Use a small dynamic loader to fix up these variables, by adding the
  difference between the load and execution address of the relevant section.
  This would require linker co-operation to generate a table of addresses that
  need fixing up.

Differential Revision: https://reviews.llvm.org/D23196

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278016 91177308-0d34-0410-b5e6-96231b3b80d8
include/clang/Basic/DiagnosticDriverKinds.td
include/clang/Driver/Options.td
lib/CodeGen/BackendUtil.cpp
lib/Driver/Tools.cpp
test/Driver/ropi-rwpi.c [new file with mode: 0644]