arm gcc aarch32编译longlong常量参数为什么跳过r1寄存器？

Question

使用工具链：

"gcc-arm-none-eabi-9-2020-q2-update"

构建 cmd：

"arm-none-eabi-gcc -MMD -g -Wno-discarded-qualifiers -O0 -mcpu=cortex-r52 -c -DGCC -mthumb -mfloat-abi=hard -mfpu=fp-armv8 -nostartfiles -ffreestanding -falign-functions=16 -falign-jumps=8 -falign-loops=8 -fomit-frame-pointer -funroll-loops printf.c -o printf.o"

发现代码：

printf("test hex long number = 0x%lx\n",  0x123456789abcdef0ul);

编译为：

  401372:   a315        add r3, pc, #84 ; (adr r3, 4013c8 <printf_test+0xd8>)
  401374:   e9d3 2300   ldrd    r2, r3, [r3]
  401378:   f245 201c   movw    r0, #21020  ; 0x521c
  40137c:   f2c0 0040   movt    r0, #64 ; 0x40
  401380:   f7ff ff76   bl  401270 <_printf>

为什么不使用“r1”寄存器作为参数传递？ 这使得“_printf”打印出乎意料。

测试十六进制长数 = 0x9abcdef000000000

如何修复或解决方法？ 让“_printf”按预期打印“0x123456789abcdef0”

Answer 1

r2/r3的使用是正确的。 AAPCS ABI指定 8 字节对象（或更准确地说，需要 8 字节对齐的对象）应在偶数/奇数寄存器对中传递。 参见第 6.3 节 C3 阶段。 这很可能使ldrd/strd可以使用，因为它们具有相同的限制。

您程序中的错误是0x123456789abcdef0ul是unsigned long long类型，尽管有ul后缀，因为它对于 32 位unsigned long来说太大了。 因此，您需要使用%llx格式说明符。 如果这样做，那么printf将正确地在r2/r3中找到参数并且一切正常。

使用原样的代码，您应该收到有关格式说明符与参数类型不匹配的编译器警告。