This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: MMU Off / Strict Alignment
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Christopher Covington <cov at codeaurora dot org>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>, "linaro-toolchain at lists dot linaro dot org" <linaro-toolchain at lists dot linaro dot org>
- Date: Tue, 17 Dec 2013 08:37:26 +0000
- Subject: Re: MMU Off / Strict Alignment
- Authentication-results: sourceware.org; auth=none
- References: <528CF7F1 dot 5050001 at codeaurora dot org> <CADSXKXqJgD3cq594+NeRk9=QHA1DKh3o7aPjsVYOx5OqT1Y6pw at mail dot gmail dot com> <52AF3E5A dot 4050507 at codeaurora dot org>
On 16/12/13 17:54, Christopher Covington wrote:
> Hi,
>
> On 11/20/2013 03:45 PM, Matthew Gretton-Dann wrote:
>> On 20 November 2013 17:57, Christopher Covington <cov@codeaurora.org> wrote:
>>> Hi,
>>>
>>> We've noticed an issue trying to use the Linaro AArch64 binary bare metal
>>> toolchain release with the MMU turned off for some low-level tests.
>>>
>>> Anytime puts, sprintf, etc. gets called, a reent structure gets created with
>>> references to STDIN, STDOUT, STDERR FILE types. A member in the __sFile
>>> struct, _mbstate, is an 8 byte struct, but is not aligned on an 8 byte
>>> boundary. This means that when memset (or a similar function) gets called on
>>> this struct, and doesn't operate one byte at a time, a data alignment fault
>>> will be generated when operating out of device memory, such as on a system
>>> where the MMU has not yet been turned on yet.
>
> We believe to have narrowed down the issue to the AArch64 optimized
> memcpy/memset implementations that assume unaligned accesses will not fault.
> While the current AArch64 libgloss startup code turns the MMU on so such
> accesses will succeed, I don't think turning on the MMU should be required of
> all startup code. Would it be possible to modify these routines to make only
> size-aligned accesses without degrading performance? If a single
> implementation can't make everyone happy, should the ifdefs around them
> perhaps be expanded to include something about requiring the MMU to be on?
>
Quite frankly, I doubt it. Good overall performance in memcpy means
avoiding hard-to-predict branches (it's not unusual for the code to be
called with completely random copy sizes); removing the unaligned
accesses would mean many more compares and branches than are currently
required, each of which would carry a significant risk of an avoidable
branch mispredict.
Furthermore, completely unaligned copies would then need to be entirely
rewritten to use byte-shifting techniques; that would significantly
impact the overall performance.
My personal feeling is that startup code is really special. If you need
to copy some memory during this time and the MMU has not been enabled,
then you can't assume that it's safe to call memcpy.
R.