[llvm-dev] A libc in LLVM

Tue Jun 25 10:41:35 PDT 2019

Many of the headers prescribed by the C specification itself have some degree of architecture-dependence. I count 11 headers that rely on some architecture details, or minimally need to have some knowledge of ABI details. These are complex, fenv, float, inttypes, limits, math, stdarg, stdatomic, stddef, stdint, and setjmp. About 10 headers have some degree of operating-system specific details (ctype, errno, signal, stdio, stdlib, wchar, wctype, threads, time, locale), although most of them have a fairly minimal abstraction base. The remaining 8 headers are truly agnostic to any implementation details and have their contents more or less mandated by the specification (assert, iso646, stdalign, stdbool, stdnoreturn, string, tgmath, and uchar), although there may be room for libraries to have accelerated implementations on particular architectures.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex Brachet-Mialot via llvm-dev
Sent: Tuesday, June 25, 2019 11:35
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] A libc in LLVM

> What do you expect to be architecture dependent? I struggled to think of where the architecture and not the operating system was the issue.

I’m also interested in this. All I can think of is longjmp.

> On Fuchsia we critically need support for AArch64

I’d be willing to work on this side of things once work gets under way but I’m with Jake that I’m not really sure what will be architecture dependent.

Best,
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/8f2b796c/attachment.html>