This is the mail archive of the
mailing list for the glibc project.
Re: framebuffer corruption due to overlapping stp instructions on arm64
- From: Florian Weimer <fweimer at redhat dot com>
- To: Andrew Pinski <pinskia at gmail dot com>, mpatocka at redhat dot com
- Cc: Catalin Marinas <catalin dot marinas at arm dot com>, Will Deacon <will dot deacon at arm dot com>, linux at armlinux dot org dot uk, thomas dot petazzoni at free-electrons dot com, linux-arm-kernel at lists dot infradead dot org, LKML <linux-kernel at vger dot kernel dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 3 Aug 2018 09:53:49 +0200
- Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
- References: <alpine.LRH.email@example.com> <CA+=Sn1mWkjuwVnjw6OWWUM=UcP76bdFa680FebCseewHfx3NpA@mail.gmail.com>
On 08/03/2018 09:11 AM, Andrew Pinski wrote:
Yes fix Links not to use memcpy on the framebuffer.
It is undefined behavior to use device memory with memcpy.
Some (de facto) ABIs require that it is supported, though. For example,
the POWER string functions avoid unaligned loads and stores for this
reason because the platform has the same issue with device memory. And
yes, GCC will expand memcpy on POWER to something that is incompatible
with device memory. 8-(
If we don't want people to use memcpy, we probably need to provide a