[llvm-dev] A libc in LLVM
Zachary Turner via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 27 15:56:33 PDT 2019
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>
More information about the llvm-dev
mailing list