[llvm-dev] A libc in LLVM

[Zachary Turner via llvm-dev]

I foresee problems with this on both Windows and non-Windows.  A
typical libc implementation has a lot of internal state that is shared
across API boundaries in a way that is considered an implementation
detail.  So making assumptions about which state is shared and which
isn't is going to be a problem.

How do you guarantee that if you implement method A and forward method
B, that B will behave the same as it would have if you had forwarded A
also?  It might not even work at all.  Where can you safely draw this
boundary?

Users can set errno for example, and in many cases they must set errno
to 0 before invoking a call if they want to reliably detect an error.
So let's say they set errno to 0, then call a method which our libc
implementation decides to forward.  What do we do?  We could propagate
errno on every single call, but my point is that there are going to be
a ton of subtle issues that arise from this approach that are hard to
foresee, precisely because the implementation details of a libc
implementation are supposed to be just that - implementation details.

On Tue, Jun 25, 2019 at 5:01 PM Siva Chandra <sivachandra at google.com> wrote:
>
> On Tue, Jun 25, 2019 at 4:32 PM Zachary Turner <zturner at roblox.com> wrote:
>>
>> The main concern I have is that Windows is so different from
>> everything else that there is a high likelihood of decisions being
>> baked in early on that make things very difficult for people to come
>> along later and contribute a Windows implementation.  This happened
>> with sanitizers for example (lack of support for weak functions on
>> Windows), LLDB (posix api calls scattered throughout the codebase),
>> and I worry with libc it will be even more difficult to correctly
>> design the abstraction because we have to deal with executable file
>> format, syscalls, operating system loaders, and various linkage
>> models.
>>
>> The most immediate thing I think we will run into is that you
>> mentioned wanting this to take shape as something that sits in between
>> system libc and application.  Given that Windows' libc and other
>> versions of libc are so different, I expect this to lead to some
>> interesting problems.
>>
>> Can you elaborate more on how you envision this working with llvm libc
>> in between application and system libc?
>
>
> A typical application uses a large number of pieces from a libc. But, it is not practical to have everything implemented and ready in a new libc from day one. So for that phase, when the new libc is still being built, we want the unimplemented parts of the new libc to essentially redirect to the system libc. This brings two benefits:
>
> 1. We can build the new libc in a gradual manner.
> 2. Applications stay operational while gaining the benefits of the new implementations.
>
> Do you foresee any problems with this approach on Windows?