[llvm-dev] A libc in LLVM

Saleem Abdulrasool via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 27 16:58:08 PDT 2019


On Thu, Jun 27, 2019 at 4:16 PM Siva Chandra via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On Thu, Jun 27, 2019 at 3:56 PM Zachary Turner <zturner at roblox.com> wrote:
>
>> No, I do not think we want to mix up CRTs on any platform. At the
>>> least, it will be disruptive to the compiler drivers. Our goal is to
>>> build a CRT with supports statically linked executables on Linux. We
>>> do not intend to mix this new CRT with the CRT from the system libc.
>>> The new CRT might only be useful after a non-trivial part of the libc
>>> has been built. Until then, we have to use the CRT from the system
>>> libc.
>>>
>>
>
>> How would you perform redirection if both copies are not linked in?  Some
>> sort of out-of-process mechanism?  Or maybe I'm misunderstanding the nature
>> of the redirection you're referring to.
>>
>
> There is probably a difference in what we mean by CRT _and_ redirectors.
> Let me try to make my meaning clear.
>
> By CRT, I am referring to the [r]crt*.o files on Linux which handle
> program startup and termination logic. I do not know if CRT means something
> else on Windows.
>

This tends to be a source of confusion.  The files that you are talking
about are not required at all.  In fact, you should start with these files
not part of the project.  These are meant for one purpose: they provide the
initialization required for the libc.  These files are inherently tied to
the implementation because they must initialise the data structures for the
exact libc implementation that they comes from.  The Windows approach here
is actually very clever: it is part of the import library that you link
against and it provides the equivalent routines.  Yes, at some point, a
libc will require initialization, but the files are there as an
implementation detail, not as an end goal.  They are implicitly
non-portable and not of any material concern to such a project.

For what it is worth, I do believe that these files do really belong in the
libc project because they are so intricately tied to the implementation of
the language.  I just think that the fact these files will be part of the
project is merely an implementation detail and should not even be part of
the discussion here.


>
> With respect to "redirectors", I do not want to get locked into an
> implementation discussion here, so let me just say that they are simply
> functions in the new libc which merely call into the system libc.
>

I think that this is actually important to understand.  This was one thing
that you pointed out as being really important to the implementation for
Linux.  I would like to understand what this approach is, because I have at
least two different approaches that I can suggest with pros and cons to
each which I have used successfully in the past.


> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/79387a03/attachment.html>


More information about the llvm-dev mailing list