<div dir="ltr"><div dir="ltr">On Mon, Aug 12, 2019 at 1:59 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 12, 2019 at 4:52 PM Siva Chandra <<a href="mailto:sivachandra@google.com" target="_blank" class="cremed">sivachandra@google.com</a>> wrote:<br>
><br>
> On Mon, Aug 12, 2019 at 1:00 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank" class="cremed">aaron@aaronballman.com</a>> wrote:<br>
> ><br>
> > > dlj added inline comments.<br>
> > ><br>
> > > The specific mechanism, however, is something that ought to be addressed in a standalone design doc. We do have such a plan for ELF, but it is fairly intricate.<br>
> ><br>
> > Do you have similar plans for non-ELF systems?<br>
><br>
> We do not currently have plans for non-ELF systems. [Others interested<br>
> can of course come up with such mechanisms for non-ELF systems and<br>
> contribute to the project.]<br>
<br>
How should I interpret the statement the bullet point stating "Ability<br>
to layer this libc over the system libc"? If this project does not<br>
consider Windows support (e.g.) out of the box, I worry we will design<br>
ourselves into unsupportable use cases. It's not that I want to commit<br>
anyone to supporting other platforms right out of the box, but LLVM<br>
supports non-ELF targets and so whatever we wind up with as a design<br>
had better also support non-ELF targets and I'm not confident that's<br>
the case here.<br></blockquote><div><br></div><div>I think there is a slight distinction in semantics to call out here: we have a specific design in mind for ELF -- i.e., what objects need to be built against the system library, and how to call those from the non-system implementation. However, at a more general level, the goal is to be portable across platforms. In that sense, Windows is already "in the plan." I read your question as taking aim at the higher level, so I would be curious as to what specifically gives you pause.</div><div><br></div><div>Personally, I agree with prior sentiment that it would be better to make Windows a target from day one... however, I could also believe that we might not gain much from an implementation that relies primarily on delegating to msvcrt. This is not a philosophical point, but rather a tradeoff between effort and benefit.</div><div><br></div><div>So, maybe a question for you: Do you think it would be reasonable to take the incremental approach while the library is being developed, rather than wait until the implementation is mature enough that it only needs to make syscalls? (With my -- admittedly limited -- knowledge of Windows internals, I think I could instead ask: do you think we gain very much by incrementally developing on top of msvcrt's libc implementation, or does it make sense to wait until we only need to call into kernel32, etc., at which point delegation to msvcrt's libc can be more selective?)</div><div><br></div><div>And as a follow-up: what else specifically do you think would need to be included in this document, versus how much belongs in a separate design document?</div></div></div>