[llvm-dev] A libc in LLVM

Siva Chandra via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 25 16:49:07 PDT 2019


On Tue, Jun 25, 2019 at 4:05 PM Jake Ehrlich <jakehehrlich at google.com>
wrote:

> Syscalls are operating system specific and architecture dependent so I
> think we'll want an abstraction layer around the fundamental operations the
> syscalls support anyway. Some things like open aren't even syscalls on all
> operating
>

Right, syscalls are OS _and_ architecture dependent. So yes, one will have
to build abstraction layers over fundamental operations in general.


> systems. There might be a generic syscall layer added that would be
> architecture and not operating system specific but even on x86_64 there are
> two different ways to do syscalls I think. Loading, startup, and linking
> are all both format and operating system specific and a few of these
> details involved are determined by the architecture but they're trivially
> abstracted away.
>
> why is answering these questions at a general level important?
>
>
> Because I wanted to make sure I understood the direction and the
> restriction stated. The restriction on what architecture will be used
> without stating a restriction on the operating system seemed like an odd
> statement. I'd very much like operating system abstractions to be
> considered right out of the gate and this seems like a bigger issue than
> the architecture to me.
>

Ah, I see what happened.
So, we are definitely not restricting anything by design here. All we are
saying is that we do not intend to contribute beyond x86_64 and Linux to
begin with. The community is free to contribute and widen the scope as
suitable.

With respect to how exactly we want to build the abstractions, I am of the
opinion that we have to go on a case by case basis. The scope of the
project is so large that I think it is more meaningful to discuss designs
at a more narrow level based on the area that is being worked on.  Sure, we
might end up discovering patterns down the road and choose to unify certain
things eventually.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/fd0236c9/attachment.html>


More information about the llvm-dev mailing list