work around arm gcc's rejection of r7 asm constraints in thumb mode
authorRich Felker <dalias@aerifal.cx>
Tue, 1 May 2018 18:34:22 +0000 (14:34 -0400)
committerRich Felker <dalias@aerifal.cx>
Tue, 1 May 2018 18:34:22 +0000 (14:34 -0400)
commite3c682ab5257aaa6739ef242a9676d897370e78e
treeb5a07bf71a14d4886bf7d9d6547fae8d88ea76cf
parent9be4ed5d89ecca80123311a4ec73781e5cc97a9c
work around arm gcc's rejection of r7 asm constraints in thumb mode

in thumb mode, r7 is the ABI frame pointer register, and unless frame
pointer is disabled, gcc insists on treating it as a fixed register,
refusing to spill it to satisfy constraints. unfortunately, r7 is also
used in the syscall ABI for passing the syscall number.

up til now we just treated this as a requirement to disable frame
pointer when generating code as thumb, but it turns out gcc forcibly
enables frame pointer, and the fixed register constraint that goes
with it, for functions which contain VLAs. this produces an
unacceptable arch-specific constraint that (non-arm-specific) source
files making syscalls cannot use VLAs.

as a workaround, avoid r7 register constraints when producing thumb
code and instead save/restore r7 in a temp register as part of the asm
block. at some point we may want/need to support armv6-m/thumb1, so
the asm has been tweaked to be thumb1-compatible while also
near-optimal for thumb2: it allows the temp and/or syscall number to
be in high registers (necessary since r0-r5 may all be used for
syscalll args) and in thumb2 mode allows the syscall number to be an
8-bit immediate.
arch/arm/syscall_arch.h