I found the following issue while developing SHA256 for ARM. It isn't an issue right now for that particular implementation, but I will share my notes here as they might be of use and to see if there is a different way of handling these cases or if the language/compiler needs improvement.

Consider the following program:

param int L = 2042; // works for 2041, fails for 2042
u32[1] H = {1};

export fn main() -> reg u32
{
  inline int i;
  reg ptr u32[1] Hp;
  reg u32 t v;

  Hp = H;
  t = Hp[0];

  v = 0;
  for i=0 to L
  { v += t; }

  return v;
}

We have a global array H, from which we get the address into Hp and then use it once. Between Hp = H; and the glob_data: section, there are 1 load, 1 move, 2042 add instructions, and a pop instruction. When I try to run arm-linux-gnueabi-gcc -g -static -mcpu=cortex-m4 -o example example.s, where example.s contains the result of compiling the previous program, I get:

globals.s: Assembler messages:
globals.s:8: Error: invalid constant (101c) after fixup

The assembly instruction corresponding to Hp = H; is ADR r0, glob_data+0. For L = 2041, the program compiles and when observing the result of objdump one can see:

f60f 70fc       addw    r0, pc, #4092   ; 0xffc

Accordingly to p.197 of this manual it seems that the T2 encoding is used, and we get 12 bits (4095) to use (I compared the bits from f60f 70fc with the ones from the pdf).

Going back to L = 2042. The reported value by the compiler is 0x101c, corresponding to 4124 in decimal. The calculation goes as follows, if I'm not mistaken: 4 bytes for Hp = H;, 6 bytes for t = Hp[0]; v=0;, 4084 bytes corresponding to the for loop (2 bytes per instruction), and 2 bytes for the last pop. Total of 4096 bytes (not considering the assembly code before Hp = H;)

Due to the .p2align 5 directive before glob_data:, this seems to put glob_data at a distance of 4124 from the ADR instruction. Hence, this constant does not fit possible encodings for the instruction.

Questions:

• Is it necessary to align global constants to 32 bytes? (I believe doing smaller alignments does not make a difference for this case, but it might help in other cases).
• How to deal with large programs / large sets of global variables/arrays in ARM? (I imagine that branching to a code section closer to the data section could work, but I'm unsure if this is the best solution for this problem).

Some final notes regarding the SHA256 implementation:

• The initial ARM implementation of SHA256 was obtained by copy-pasting the amd64 implementation with some minor adjustments (large implementation; previously described problem observed);
• Since having a small implementation was the final goal, I wrote some temporary functions to initialize the corresponding constants directly into a stack array to have a working implementation;
• Refactored the ARM implementation to be "small", which made the previous error disappear. Nonetheless, this issue may appear in future implementations.