[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

> On 6/25/19 7:22 PM, Zachary Turner via llvm-dev wrote:
> > 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.

+1 for what Hal Finkel has said below about switching from redirectors
to implementations: There will be certain groups of functions which
will have to be switched all together. We will not be able to do it
one function at a time for such groups.

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

Are you talking about a scenario wherein implementation of B in the
system libc calls its A? If yes, most libc implementations do a good
job of using internal names in such scenarios. That is, B would call A
with an internal name. This ensures that B from the system libc calls
A also from the system libc and not the redirector/forwarder.

> > 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.

Dealing with errno in particular is probably not as nasty as it seems.
The standard allows errno to be a macro. Hence, for the transitory
phase, implementations and redirectors in our libc can make use of the
errno from the system libc. Something like this:

$> cat llvm-errno.cpp
#include <errno.h>  // This is the system-libc header file

int *__llvm_errno() {
  return &errno;
}

$> cat errno.h  # This is the llvm libc's errno.h
int *__llvm_errno();

#define errno (*__llvm_errno())

On Tue, Jun 25, 2019 at 6:20 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:
> You certainly can't mix-and-match on a per-function level, in general. I
> suspect that there are some subsystems that can be substituted. Using
> open from one libc and close from another seems problematic. Using open
> and close from one libc and qsort from another is probably fine. And, as
> you point out, the library might need to be configurable to use an
> externally-provided errno.