On Mon, Sep 21, 2020 at 5:41 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > Like arm64, ARM supports position independent code sequences that > produce symbol references with a greater reach than the ordinary > adr/ldr instructions. Since on ARM, the adrl pseudo-instruction is > only supported in ARM mode (and not at all when using Clang), having > a adr_l macro like we do on arm64 is useful, and increases symmetry > as well. > > Currently, we use open coded instruction sequences involving literals > and arithmetic operations. Instead, we can use movw/movt pairs on v7 > CPUs, circumventing the D-cache entirely. > > E.g., on v7+ CPUs, we can emit a PC-relative reference as follows: > > movw <reg>, #:lower16:<sym> - (1f + 8) > movt <reg>, #:upper16:<sym> - (1f + 8) > 1: add <reg>, <reg>, pc > > For older CPUs, we can emit the literal into a subsection, allowing it > to be emitted out of line while retaining the ability to perform > arithmetic on label offsets. > > E.g., on pre-v7 CPUs, we can emit a PC-relative reference as follows: > > ldr <reg>, 2f > 1: add <reg>, <reg>, pc > .subsection 1 > 2: .long <sym> - (1b + 8) > .previous > > This is allowed by the assembler because, unlike ordinary sections, > subsections are combined into a single section in the object file, and > so the label references are not true cross-section references that are > visible as relocations. (Subsections have been available in binutils > since 2004 at least, so they should not cause any issues with older > toolchains.) > > So use the above to implement the macros mov_l, adr_l, ldr_l and str_l, > all of which will use movw/movt pairs on v7 and later CPUs, and use > PC-relative literals otherwise. > > Reviewed-by: Nicolas Pitre <nico@xxxxxxxxxxx> > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> That is obviously a very neat tool you have there. I worry a bit that people reading the code might have to issue git log/blame on it to get the commit message in order to understand what is going on. Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Yours, Linus Walleij
