[RFC] Improve newlib source code compatibility with LLVM clang

[Volodymyr Turanskyy]

Hi Joel,

Thank you for looking into this!

I just sent 3 smaller patches – you are correct that some of the changes are more like workarounds, e.g. the commented out linux-crt0.c:353 – it is not used in an embedded environment, while reworking it to meet clang expectations would be quite some effort (that we would not have a way to test again as it is not used in embedded).

Sincerely,

Volodymyr Turanskyy | Principal Software Engineer | CE SW LLVM Team

From: Joel Sherrill <joel.sherrill@gmail.com>
Date: Monday, 20 January 2025 at 14:42
To: Volodymyr Turanskyy <Volodymyr.Turanskyy@arm.com>
Cc: newlib@sourceware.org <newlib@sourceware.org>, nd <nd@arm.com>
Subject: Re: [RFC] Improve newlib source code compatibility with LLVM clang

If [2] is the only patch, it looks mostly safe and straightforward to me at first glance. Mostly adding a "p" in front of numeric register references, a lower addition, and a few ifdef's on __clang__ to avoid unsupported directives. But info documentation is hacked out and there is the addition of __aarch64_sme_accessible() without explanation.

rdimon-aem.S;208 has a replacement of 1 instruction with 2 with no explanation.

linux-crt0.c:353 comments out the attribute naked with a C++ comment. I don't think C++ comments are allowed. If this really needs to disappear, it likely should just be deleted.

My preference would be a series of patches with specific purposes. For example, a first patch which adds "p" in front of all the register numbers. That should eliminate a lot of this patch.

I would like functional additions to be separate from addressing syntax issues.

Is there anything in there more substantial that I missed?

--joel

On Mon, Jan 20, 2025 at 7:13 AM Volodymyr Turanskyy <Volodymyr.Turanskyy@arm.com<mailto:Volodymyr.Turanskyy@arm.com>> wrote:
Hello,

LLVM Embedded Toolchain for Arm [1] uses newlib as one of libraries for embedded development, with a lot of interest from users. Unfortunately, newlib cannot be built with LLVM clang out-of-box, because of minor source code issues, so the project has to maintain a rather big patch [2] on top of newlib.

Most of the issues are in the assembly syntax, straightforward to fix in a way to be supported by both GCC and clang.

We want to share a series of small patches to update the syntax to improve compatibility with both compilers. I will send individual patches to the mail list as separate emails for further discussion.

Note that if there is interest from the newlib community, we would be happy to setup a CI that would try to build latest version of newlib to show if any new incompatibilities are introduced, however we would not have time to fix all of them in timely manner as our focus is on LLVM development.

References:

1.     https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm

2.     https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/blob/main/patches/newlib/0001-Enable-newlib-build.patch

Sincerely,

Volodymyr Turanskyy | Principal Software Engineer | CE SW LLVM Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20250120/61ca478b/attachment-0001.htm>