[PATCH] D64939: Add a proposal for a libc project under the LLVM umbrella.

[David Jones via llvm-commits]

On Mon, Aug 12, 2019 at 1:59 PM Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Mon, Aug 12, 2019 at 4:52 PM Siva Chandra <sivachandra at google.com>
> wrote:
> >
> > On Mon, Aug 12, 2019 at 1:00 PM Aaron Ballman <aaron at aaronballman.com>
> wrote:
> > >
> > > > dlj added inline comments.
> > > >
> > > > 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.
> > >
> > > Do you have similar plans for non-ELF systems?
> >
> > We do not currently have plans for non-ELF systems. [Others interested
> > can of course come up with such mechanisms for non-ELF systems and
> > contribute to the project.]
>
> How should I interpret the statement the bullet point stating "Ability
> to layer this libc over the system libc"? If this project does not
> consider Windows support (e.g.) out of the box, I worry we will design
> ourselves into unsupportable use cases. It's not that I want to commit
> anyone to supporting other platforms right out of the box, but LLVM
> supports non-ELF targets and so whatever we wind up with as a design
> had better also support non-ELF targets and I'm not confident that's
> the case here.
>

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.

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.

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?)

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190812/d068b1d4/attachment.html>