On Thu, Jun 27, 2019 at 9:06 AM Zachary Turner <zturner at roblox.com> wrote:> I guess let me make this concrete: can you propose a specific separation that you have in mind? > > Keep in mind that even if A doesn’t depend on B, that doesn’t mean that A and B can be separated. You mentioned that open() and close() would obviously have to be done at the same time, but it’s much worse than this: The *entire transitive closure* of open() and close() must be done at the same time, and my hypothesis is that this is going to a) be much larger than you expect, and b) be different with different underlying libc implementations.Let me change the direction here a little bit. Lets say, for Windows, you can develop the new libc starting from a clean slate without having to worry about the redirectors/forwarders. Is that a good enough place for you to start? What I am getting to is this: redirectors are probably an implementation detail at this point. We think they will allow us to develop and phase-in this libc in a gradual manner. But, if they end up being a problem on other platforms, we will build them in such a way that they only stay as Linux specific implementation details. If other platforms can benefit from them, they are of course free to adopt them.> Then there are more immediate issues. On Windows specifically, I’m not even sure it’s going to be physically possible to link in two copies of the CRT and have one forward to the other. If it is possible, it’s very non obvious how to make it work and will likely require a ton of additional machinery.No, I do not think we want to mix up CRTs on any platform. At the least, it will be disruptive to the compiler drivers. Our goal is to build a CRT with supports statically linked executables on Linux. We do not intend to mix this new CRT with the CRT from the system libc. The new CRT might only be useful after a non-trivial part of the libc has been built. Until then, we have to use the CRT from the system libc.
On Thu, Jun 27, 2019 at 3:39 PM Siva Chandra <sivachandra at google.com> wrote:> On Thu, Jun 27, 2019 at 9:06 AM Zachary Turner <zturner at roblox.com> wrote: > > I guess let me make this concrete: can you propose a specific separation > that you have in mind? > > > > Keep in mind that even if A doesn’t depend on B, that doesn’t mean that > A and B can be separated. You mentioned that open() and close() would > obviously have to be done at the same time, but it’s much worse than this: > The *entire transitive closure* of open() and close() must be done at the > same time, and my hypothesis is that this is going to a) be much larger > than you expect, and b) be different with different underlying libc > implementations. > > Let me change the direction here a little bit. Lets say, for Windows, > you can develop the new libc starting from a clean slate without > having to worry about the redirectors/forwarders. Is that a good > enough place for you to start? >It's probably a good enough place for me to start, yes. I still have reservations -- even for the Linux case -- about whether it will be possible to make a reasonable separation of library calls in such a way that set A redirects, set B doesn't redirect, and everything works without any issues, but as long as the general community isn't locked into such a model for every platform, then I guess it can be up to the platform owners to work those issues on their own.> > > Then there are more immediate issues. On Windows specifically, I’m not > even sure it’s going to be physically possible to link in two copies of the > CRT and have one forward to the other. If it is possible, it’s very non > obvious how to make it work and will likely require a ton of additional > machinery. > > No, I do not think we want to mix up CRTs on any platform. At the > least, it will be disruptive to the compiler drivers. Our goal is to > build a CRT with supports statically linked executables on Linux. We > do not intend to mix this new CRT with the CRT from the system libc. > The new CRT might only be useful after a non-trivial part of the libc > has been built. Until then, we have to use the CRT from the system > libc. >How would you perform redirection if both copies are not linked in? Some sort of out-of-process mechanism? Or maybe I'm misunderstanding the nature of the redirection you're referring to. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/ed0226a9/attachment.html>
On Thu, Jun 27, 2019 at 3:56 PM Zachary Turner <zturner at roblox.com> wrote:> No, I do not think we want to mix up CRTs on any platform. At the >> least, it will be disruptive to the compiler drivers. Our goal is to >> build a CRT with supports statically linked executables on Linux. We >> do not intend to mix this new CRT with the CRT from the system libc. >> The new CRT might only be useful after a non-trivial part of the libc >> has been built. Until then, we have to use the CRT from the system >> libc. >> >> How would you perform redirection if both copies are not linked in? Some > sort of out-of-process mechanism? Or maybe I'm misunderstanding the nature > of the redirection you're referring to. >There is probably a difference in what we mean by CRT _and_ redirectors. Let me try to make my meaning clear. By CRT, I am referring to the [r]crt*.o files on Linux which handle program startup and termination logic. I do not know if CRT means something else on Windows. With respect to "redirectors", I do not want to get locked into an implementation discussion here, so let me just say that they are simply functions in the new libc which merely call into the system libc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/ab323421/attachment.html>