Tim Northover via llvm-dev
2016-Apr-11 14:12 UTC
[llvm-dev] 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.
Renato Golin via llvm-dev
2016-Apr-11 14:42 UTC
[llvm-dev] compler-rt, __aeabi_memcpy () possibly broken (ARM)
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
Joerg Sonnenberger via llvm-dev
2016-Apr-11 18:28 UTC
[llvm-dev] compler-rt, __aeabi_memcpy () possibly broken (ARM)
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
Peter Jakubek via llvm-dev
2016-Apr-11 19:16 UTC
[llvm-dev] compler-rt, __aeabi_memcpy () possibly broken (ARM)
> > 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