[llvm-bugs] [Bug 35243] New: Some Arm __aeabi_ builtin implementations are not ABI Compliant

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35243

            Bug ID: 35243
           Summary: Some Arm __aeabi_ builtin implementations are not ABI
                    Compliant
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: peter.smith at linaro.org
                CC: llvm-bugs at lists.llvm.org

The Run Time ABI for the Arm Architecture:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf 
restricts the registers that some __aeabi_ function implementations can
corrupt. This means that it may not be safe to implement these functions in
plain C, or call out to other AAPCS compliant functions as these may have a
larger set of registers that they are able to corrupt, for example the floating
point argument registers.   

There are some implementations of these functions in compiler-rt that forward
on to generic C implementations, for example __aeabi_memcpy forwards to memcpy.
This is not safe as the implementation of memcpy in the C-library may corrupt
the floating point/vector registers.

By my reading of the Run Time ABI the following __aeabi_ functions have
restrictions.

3 Way floating point comparison operations
void __aeabi_cdcmpeq(double, double)
void __aeabi_cdcmple(double, double)
void __aeabi_cdrcmple(double, double)
void __aeabi_cfcmpeq(float, float)
void __aeabi_cfcmple(float, float)
void __aeabi_cfrcmple(float, float)

"The 3-way, status-returning comparison functions preserve all core registers
except ip, lr, and the CPSR"

The long long helper functions:
long long __aeabi_lmul(long long, long long) 
long long __aeabi_llsl(long long, int)
long long __aeabi_llsr(long long, int)
long long __aeabi_lasr(long long, int)
int __aeabi_lcmp(long long, long long)
int __aeabi_ulcmp(unsigned long long, unsigned long long)

[Apart from ldivmod and uldivmod, which have full AAPCS privileges]
"Otherwise, implementations of the long long helper functions are allowed to
corrupt only the integer core registers permitted to be corrupted by the AAPCS
(r0-r3, ip, lr, and CPSR)."

Unaligned memory access:
int __aeabi_uread4(void *address);
int __aeabi_uwrite4(int value, void *address);
long long __aeabi_uread8(void *address);
long long __aeabi_uwrite8(long long value, void *address);

"Implementations of these functions are allowed to corrupt only the integer
core registers permitted to be corrupted by the [AAPCS] (r0-r3, ip, lr, and
CPSR)."

Memory copying, clearing, and setting:
void __aeabi_memcpy8(void *dest, const void *src, size_t n);
void __aeabi_memcpy4(void *dest, const void *src, size_t n);
void __aeabi_memcpy(void *dest, const void *src, size_t n);
void __aeabi_memmove8(void *dest, const void *src, size_t n);
void __aeabi_memmove4(void *dest, const void *src, size_t n);
void __aeabi_memmove(void *dest, const void *src, size_t n);
void __aeabi_memset8(void *dest, size_t n, int c);
void __aeabi_memset4(void *dest, size_t n, int c);
void __aeabi_memset(void *dest, size_t n, int c);
void __aeabi_memclr8(void *dest, size_t n);
void __aeabi_memclr4(void *dest, size_t n);
void __aeabi_memclr(void *dest, size_t n);

"In general, implementations of these functions are allowed to corrupt only the
integer core registers permitted to
be corrupted by the [AAPCS] (r0-r3, ip, lr, and CPSR)."

For the other "floating point helper functions", there is this paragraph:
"If the FP instruction set is available, implementations of these functions may
use it. Consequently, FP hardware using code that calls one of these helper
functions directly, or indirectly by calling a function with a base-standard
interface, must assume that the FP parameter, result, scratch, and status
registers might be altered by a call to it."

My reading of the AAPCS is that these corruptible registers match the same set
that a floating point using C function can corrupt so there isn't a problem
with functions in "The floating-point helper functions" being implemented in C.

At present I think the main area of non-compliance for the __aeabi_ functions
that compiler-rt implemnts are those in "Memory copying, clearing, and setting"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171108/a45b4e66/attachment-0001.html>