Skip to content
Snippets Groups Projects
  1. Dec 14, 2016
  2. Nov 22, 2016
  3. Nov 18, 2016
  4. Nov 11, 2016
  5. Nov 07, 2016
  6. Oct 19, 2016
  7. Oct 04, 2016
  8. Sep 23, 2016
  9. Sep 19, 2016
  10. Sep 14, 2016
  11. Aug 30, 2016
  12. Aug 17, 2016
  13. Aug 12, 2016
  14. Aug 08, 2016
    • Oliver Stannard's avatar
      [ARM] Command-line options for embedded position-independent code · 9acb854c
      Oliver Stannard authored
      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
      9acb854c
  15. Jul 29, 2016
  16. Jul 27, 2016
  17. Jul 23, 2016
  18. Jul 15, 2016
  19. Jul 10, 2016
  20. Jun 23, 2016
  21. Jun 22, 2016
  22. Jun 21, 2016
  23. Jun 02, 2016
  24. May 29, 2016
  25. May 27, 2016
  26. May 25, 2016
  27. May 24, 2016
  28. May 20, 2016
  29. May 19, 2016
  30. May 16, 2016
  31. May 11, 2016
Loading