[AArch64] nosys.specs and printf

[Alexander Fedotov]

Here is a patch to correct libnosys configuration for aarch64.
Linker warning still be emitted as agreed.

Alex

On Fri, Sep 22, 2017 at 11:05 AM, Tamar Christina
<Tamar.Christina@arm.com> wrote:
>
>
>> -----Original Message-----
>> From: Alexander Fedotov [mailto:alfedotov@gmail.com]
>> Sent: 20 September 2017 16:24
>> To: Jon Beniston
>> Cc: Tamar Christina; newlib@sourceware.org; nd
>> Subject: Re: [AArch64] nosys.specs and printf
>>
>> >>That's not doing anything other than setting errno to ENOSYS to indicate
>> it's not available.
>> Yes the same as ARM.
>>
>> So to sum up. We have several points:
>> 1. ARM port doesn't warn user about missing _write(). While this function is
>> present in final ELF and does nothing.
>> 2. AArch64 warns "warning: _write() is not implemented and will always fail"
>> while _write() it is present in ELF.
>
> Both of these are probably correct, while I consider the ARM behaviour to be the incorrect one
> It may be so for historical reasons. I'm not really sure.
>
>> 3. libnosys has inconsistent configuration against rdimon. It is impossible to
>> switch between rdimon.specs and nosys.specs.
>
> I don't quite get what you mean with this, but I assume you mean that using nosys.specs with AArch64
> Results in link errors if you use I/O. Again this is because we don't support nosys for AArch64.
>
> That said, a patch to have libnosys compile (with warnings) for AArch64 would be fine.
>
> Tamar.
>>
>> Thoughts ?
>>
>> Alex
>>
>> On Wed, Sep 20, 2017 at 5:08 PM, Jon Beniston <jon@beniston.com> wrote:
>> >> Well at least _write is here:
>> >
>> > That's not doing anything other than setting errno to ENOSYS to indicate it's
>> not available.
>> >
>> >
>>
>>
>>
>> --
>> Best regards,
>> AF



-- 
Best regards,
AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-adjust-libnosys-config-for-aarch64-to-avoid-linker-e.patch
Type: text/x-patch
Size: 995 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20171002/87c0ea59/attachment.bin>