On 18/12/13 05:06, Jonathan S. Shapiro wrote:
> At the risk of sticking my nose in, this isn't a startup code issue.
> It's a contract issue.
>
> First, I don't buy Richard's argument about memcpy() startup costs and
> hard-to-predict branches. We do those tests on essentially every
> *other* RISC
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 wrote:
>>> Hi,
>>>
>>> We've noticed an issue trying to use the Linaro AArch64 binary bare metal
>>> toolchain release with the MMU tur
Hi,
On 11/20/2013 03:45 PM, Matthew Gretton-Dann wrote:
> On 20 November 2013 17:57, Christopher Covington 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, sprin
On 20 November 2013 17:57, Christopher Covington 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
> refer
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
st
