[PATCH] D24462: [ARM] Don't convert switches to lookup tables of pointers with ROPI/RWPI

Oliver Stannard via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 26 02:33:57 PDT 2016


olista01 added a comment.

The problem here is that this pass can create new global variables, which the backend can't recognise as jump tables (they may not actually be jump tables, as they could be tables of pointers to data).

There are a few different ways that ROPI/RWPI can be made to support pointers to globals in source code, with varying requirements on the rest of the compiler:

1. Don't do anything special, the user will have to modify their code to avoid global variables initialised to the address of a global or function. This is currently done by clang, and requires that global pointers are not introduced by LLVM.
2. Add dynamic initialisers in the frontend, called from the .init_array section. This is currently done by armclang (our clang-based bare-metal toolchain). We chose this option because it allows moving constants to a read-write section if they need dynamic initialisation, and emitting diagnostics for some C constructs that may not work properly with ROPI/RWPI. This also requires that global pointers are not introduced by LLVM.
3. Use a small dynamic loader to fix-up any global pointers. This requires linker and runtime library support, I'm not aware of any implementations of this. This wouldn't be able to fix up constants when they are loaded into ROM. This would allow the compiler to introduce global pointers, but would require them to be in a read-write section, so that their value can be adjusted by the loader.

This change supports the first two, the other option would be to modify this pass to emit all lookup tables containing pointers as variables rather than constants (and possibly modify globalopt to avoid undoing that transformation). I prefer turning off this optimisation for pointers in ROPI/RWPI modes, as it avoids embedding too much knowledge about a rather unusual ARM-specific ABI in the midend.


https://reviews.llvm.org/D24462





More information about the llvm-commits mailing list