<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 4:49 PM Siva Chandra via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Jun 25, 2019 at 4:05 PM Jake Ehrlich <<a href="mailto:jakehehrlich@google.com" target="_blank">jakehehrlich@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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 </div></blockquote><div><br></div><div>Right, syscalls are OS _and_ architecture dependent. So yes, one will have to build abstraction layers over fundamental operations in general.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">why is answering these questions at a general level important? </blockquote><div><br>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.</div></div></blockquote><div><br></div><div>Ah, I see what happened.</div><div>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.</div></div></div></blockquote><div><br></div><div>IMO It is perfectly fine to have a favorite target in mind that you want to put your effort to support.</div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>Cheers,</div><div><br></div><div>-- <br></div><div>Mehdi</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>