[cfe-dev] What are the plans for creating a Windows Binary Release of Clang?

[Joshua Cranmer 🐧]

On 11/11/2013 3:17 PM, Sean Silva wrote:
>
>
>
> On Mon, Nov 11, 2013 at 3:30 PM, Devin Crumb <bitogre at gmail.com 
> <mailto:bitogre at gmail.com>> wrote:
>
>     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.
>
>
> 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:
>
> * 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?

I can see two benefits:
1. We could better customize the headers to improve optimization within 
LLVM (e.g., annotating alias information more precisely, etc.)
2. Depending on how a C library is designed, it could better facilitate 
cross-compilation under certain scenarios.
>
> * 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"?

There's also eglibc and newlib.
>
> * How realistic is it to implement a windows libc? A couple things 
> that come to mind are:
>   - 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?)
>   - Are those interfaces stable and documented?

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.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131112/f3fedea8/attachment.html>