<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/11/2013 3:17 PM, Sean Silva
wrote:<br>
</div>
<blockquote
cite="mid:CAHnXoak92=x9OgaVQJrOTzPN3RwuSS8qugGXx1M4ucC-tY3iTQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Nov 11, 2013 at 3:30 PM,
Devin Crumb <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bitogre@gmail.com" target="_blank">bitogre@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">I am definitely interested in contributing
to such an effort and fully support the idea of trying
to make an LLVM libc as cross platform as possible (and
have some experience in this area). However, I want to
understand what is going to be expected of me if I am
the one to actually start the effort before taking on
such a commitment.</div>
</blockquote>
<div><br>
</div>
<div>Any significant new block of code will generally
require a long-term maintenance commitment. However, for a
libc I'm sure there are a bunch of things to do that don't
require as much of a commitment. In particular, I think it
would be useful to pin down the following:</div>
<div><br>
</div>
<div>* Try to explore the realistic benefits of having our
own libc. I'm not entirely convinced that having our own
libc will be a huge win, or at least not enough to justify
the huge amount of work it would entail. We seem to get
along just fine (?; at least in my experience) without
having to "own" the libc. What are the "pain points" that
would be soothed by having our own libc, and on what
platforms?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I can see two benefits:<br>
1. We could better customize the headers to improve optimization
within LLVM (e.g., annotating alias information more precisely,
etc.)<br>
2. Depending on how a C library is designed, it could better
facilitate cross-compilation under certain scenarios.<br>
<blockquote
cite="mid:CAHnXoak92=x9OgaVQJrOTzPN3RwuSS8qugGXx1M4ucC-tY3iTQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
</div>
<div><br>
</div>
<div>* Survey existing libc's and write-up their current
portability situation, licensing, implementation quality,
etc. Off the top of my head, some libc's that I know
about: musl, uclibc, bionic, glibc,
{Free,Open,Net,...}BSD's libc, OpenSolaris (illumos) libc.
Is it really necessary to roll our own, or can one of
these existing ones be adapted to soothe the biggest "pain
points"?</div>
</div>
</div>
</div>
</blockquote>
<br>
There's also eglibc and newlib.<br>
<blockquote
cite="mid:CAHnXoak92=x9OgaVQJrOTzPN3RwuSS8qugGXx1M4ucC-tY3iTQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>* How realistic is it to implement a windows libc? A
couple things that come to mind are:</div>
<div> - What is the "lowest level" interface that the libc
is going to be built on top of (I'm clueless about
windows, but for example Linux has a documented and stable
syscall ABI, which is trivial to interoperate with; is
there an equivalent of that on Windows? or Mac?)</div>
<div> - Are those interfaces stable and documented?</div>
</div>
</div>
</div>
</blockquote>
<br>
An elephant in the room is that the C standard library is
comparatively weak in terms of useful platform abstractions, so what
you could call libc.so.6 or msvcrt.dll goes above and beyond what
you'd find in C11 and include things like POSIX, etc. Not all of
these abstractions make sense on all platforms (IPC doesn't really
exist as a useful concept in some embedded domains, e.g.). The
asymmetry between Windows' (MSVC's) general lack of POSIX support
and near-universal POSIX support on other platforms means that
supporting the extended-not-C-library API in a cross-platform manner
raises some concerns. Not insurmountable ones, but ones that require
a great deal of planning before rushing headlong into code.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>