[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

On Tue, Jun 25, 2019 at 10:41 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

> 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).
>
>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
Right. If my first email sounded like we care only about x86_64 and Linux,
let me improve on it: Our intention is not to design out any particular
platform. At this point in time, the team I represent is most interested in
Linux and x86_64. We intend to do all development in the open from day one.
So, we will be looking up to the community members interested in other
platforms to bring their views and needs and help build stronger
abstractions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/582251b1/attachment.html>