[llvm-dev] A libc in LLVM

[Mehdi AMINI via llvm-dev]

On Tue, Jun 25, 2019 at 4:49 PM Siva Chandra via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>

IMO It is perfectly fine to have a favorite target in mind that you want to
put your effort to support.
However if the project is not started from the ground up by involving
people that care about other platforms (and you have enough variety of
these), then it is likely that assumptions about your favorite platform
will be baked in the foundations of the project and it'll be technically
hard for the community to re-use these pieces in the future or contribute
support for their platform (I'm making a similar point to Zach here).

If we must have a libc in LLVM, I hope it will be designed and implemented
from the beginning with multiple OS and at least two architectures from the
beginning. Even if you only really care about X86/Linux, you may have to
put some minimal amount of effort to support Windows just to prove your
design (ideally there would be enough support in the community so that
putting effort to support Windows isn't only on you).

Cheers,

-- 
Mehdi




>
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/fb6b4c4c/attachment.html>