llvm dev - Apr 2016 - compler-rt, __aeabi_memcpy () possibly broken (ARM)

On 11 April 2016 at 02:43, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> This is standard AAPCS, I trully hope neither glibc, newlib or musl's
> implementations will corrupt anything more.
Normal AAPCS functions are allowed to corrupt d0-d7 and d16-d31, but
the RTABI seems pretty explicit that these functions aren't. I think
we've got a real problem here.

Cheers.

Tim.

On 11 April 2016 at 15:12, Tim Northover <t.p.northover at gmail.com>
wrote:
> Normal AAPCS functions are allowed to corrupt d0-d7 and d16-d31, but
> the RTABI seems pretty explicit that these functions aren't. I think
> we've got a real problem here.
Hum... (went to read the AAPCS again), right.

I'm guessing we haven't got that problem yet because no one uses those
registers or they save/restore. But this is a potential problem, yes.

On free-standing environments (Linux), Vinicius fixed the need for
__aeabi_mempcy to point to memcpy, so we could remove RT's copy if
it's only about Linux (and possibly Android's bionic). But I don't
know about BSD or OSX.

However, implementing a crude version of those functions in RT is not
a solution, as we're bound to get many things wrong for a long time.

cheers,
--renato

On Mon, Apr 11, 2016 at 03:42:35PM +0100, Renato Golin via llvm-dev
wrote:
> On free-standing environments (Linux), Vinicius fixed the need for
> __aeabi_mempcy to point to memcpy, so we could remove RT's copy if
> it's only about Linux (and possibly Android's bionic). But I
don't
> know about BSD or OSX.
I'm not using it in NetBSD at least, __aeabi_memcpy and co are provided
by libc. That said, it is just an alias for memcpy in libc either and
not using FP.

Joerg

>
> I'm guessing we haven't got that problem yet because no one uses
those
> registers or they save/restore. But this is a potential problem, yes.
>
The reason we probably don't have a problem is that LLVM does not seem to
assume the float registers remain unchanged when it generates a call to
__aeabi_memcpy. Even though it could.

That way it doesn't matter whether memcyp is called (and corrupts these 
registers).

As long as we can guarantee this is always the case, there won't be a 
problem
with LLVM, compiler-rt. Can we guarantee?

BTW, newlib's memcpy () is an example that corrupts float registers. So 
we can't
assume these do not exist.

Cheers,

Peter