This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/5] Using LLVM (DragonEgg) to compile glibc


On 05/13/2013 11:36 AM, Peter Collingbourne wrote:
> Hi,
> 
> I've been working on using LLVM to compile glibc.  There are a couple
> of main motivations for this:
> 
> 1) Allowing for investigation of runtime performance differences between
>    GCC and LLVM wrt glibc.
> 
> 2) Allowing for LLVM's instrumentation based dynamic analyses
>    (e.g. MemorySanitizer, a tool for detecting use of uninitialised
>    memory) to be applied to glibc, thereby allowing us to instrument
>    every function in an executable.  With the guarantee of every
>    function being instrumented:
>     a) We can accurately instrument an executable including its calls
>        to libc.
>     b) We can safely use the instrumentation pass to alter
>        the internal ABI of the executable (which can potentially give a
>        performance boost), without having to worry about calls between
>        instrumented and uninstrumented code.  (This isn't entirely
>        accurate given the presence of asm-based syscall wrappers,
>        but there are ways around that.)
> 
> While glibc is already quite GCC-dependent, it can (almost) be
> compiled using DragonEgg, a GCC plugin that replaces GCC's optimisers
> and backend with LLVM's.  In the process of doing this port I had to
> modify glibc in a number of ways, most of which fix what I consider
> to be bugs in glibc (which could in principle be exposed by later
> versions of GCC or the rest of the toolchain).  The patches provided
> below contain those changes, and take us a good part of the rest of
> the way to being able to compile a working glibc using DragonEgg.
> (There are a handful of tests, particularly floating point tests,
> in the glibc test suite which fail, but it isn't feasible for me to
> fix those at the moment.)

Peter,

We are a consensus driven community, so if you get enough ACK's
for your patches and work through the objections presented then
you should feel free to ask someone to check it in for you.

Alternatively you could express an interest in helping to continue
to maintain glibc's ability to be compiled by LLVM and ask for
a sourceware account and permission to checkin the glibc changes
yourself :-)

http://sourceware.org/glibc/wiki/MAINTAINERS#Becoming_a_maintainer

http://sourceware.org/glibc/wiki/MAINTAINERS#Source_Control_ACLs

Cheers,
Carlos. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]