[llvm-dev] How to compile glibc with clang/llvm?

[xuruobin via llvm-dev]

To whom it may concern,

Is there a way to build glibc with clang/llvm? I’m working on enabling llvm-cov for my compiler which is a totally new arch with a libc.a built from newlib. I successfully built compiler-rt but when I typed the command ` clang++ --target=xxx -fprofile-instr-generate -fcoverage-mapping foo.cc -o foo`, the linker failed because of undefined reference to `mmap'/`ftruncate'/`mkdir'. I found these functions are supported by glibc but I cannot bulid glibc with clang/llvm(configure gave me an error “These critical programs are missing or too old: compiler”). So I want to know how can I compile glibc with clang/llvm or are there some WIP patches to help me with this requirement?

Thanks,
Ruobin.
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Kristina Brooks via llvm-dev]

Hi.

I've managed to do it before, with a lot of patches to Glibc, as well as ld.so and getting basic programs to start with
it. However, a lot of tests did not pass and in general I abandoned it due to the fact that Glibc source code is not
very easy to work with.

I can upload it somewhere, not sure if there is any general interest in this kind of thing. I think current GRTE may
also be build-able with Clang (my fork was based on older GRTE which had unfinished patches to support Clang), though I
haven't had the time to look at that recently.

I should add a huge disclaimer: this won't be easy and requires understanding the macro hell in glibc, GRTE relies on
some hacky uses of `_Pragma` to supplement for some macros otherwise not possible with Clang. Even if you do get it to
build I think it may be a waste of time to try and just implement the missing symbols in your case (or figure out why
they're not being exported).

Thanks.

[Kristina Brooks via llvm-dev]

Hi.

Actually from reading the README, it seems to imply that it can be built
with Clang 6.0.0 and above now, though it does incorporate a lot of patches not
specific to Clang building so you will end up with them as well:

----------------------------------------------------------------------------
BUILDING GRTE WITH CLANG

GRTE v5 and later can also be built with clang and (optionally) lld.
LLVM support for GNU source code continues to evolve (as of June
2018), so the process is less straightforward, and likely to change
from what is documented here. There are a number of glibc patches
that make this work, including additional configure options mentioned
below.

The minimum version of clang is 6.0.0. If lld is to be used for linking,
it needs to be newer than 6.0.0.

Configure:

CC=path-to-llvm/clang CXX=path-to-llvm/clang++ \
../glibc/configure --disable-werror --with-clang --disable-float128 \
--with-lld --with-default-link --disable-multi-arch --prefix=/something
------------------------------------------------------------------------------

[Alberto Barbaro via llvm-dev]

Hi,

Could you keep us posted, or at least me? I'm interested to compile glibc as well and obtain the bitcode.

Would you consider to use https://www.musl-libc.org in the meantime?

Thanks

[blubee blubeeme via llvm-dev]

GNU likes to use non standard extensions for convenience while LLVM/Clang would like stick to the standards.

Unless GNU adopts a more standards compliant behavior OR LLVM decides to relax their adherence to the standards

the tools will always be somewhat incompatible w/o major work.

For example recent changes to the Linux Kernel adopted GNU goto asm; which means that Clang will not compile

the kernel; 

I am not sure how far LLVM is willing to bend over to please the GNU nor am I certain GNU will become more

standards complaint anytime soon.

You might try the route of patching glibc but that might not be the best use of your time.

There are other c implementations out there.

Best

[Kristina Brooks via llvm-dev]

Such is the case for most compilers, Clang supports extensions such as blocks for example, which IIRC date
back to before C++11 lambdas or around the same time. There's a lot of other implementation specific differences
for example in attributes.

Anyway, skipping that point, Glibc upstream isn't actively trying to work with Clang compliant unlike mainline Linux,
as you may guess from the name Glibc is a GNU libc, aimed to work and be built by the GNU Compiler Collection aka
GCC. If we look at a non-GNU libc such as, say, Bionic, currently it's built with a Clang based toolchain.

If you want a starting point for building Glibc forks with Clang, I mentioned one already, if the documentation
is correct, it has decent Clang support but YMMV.

On 23/12/2018 18:53, blubee blubeeme wrote:
> GNU likes to use non standard extensions for convenience while LLVM/Clang would like stick to the standards.
>
> Unless GNU adopts a more standards compliant behavior OR LLVM decides to relax their adherence to the standards
> the tools will always be somewhat incompatible w/o major work.
>
> For example recent changes to the Linux Kernel adopted GNU goto asm; which means that Clang will not compile
> the kernel; 
>
> I am not sure how far LLVM is willing to bend over to please the GNU nor am I certain GNU will become more
> standards complaint anytime soon.
>
> You might try the route of patching glibc but that might not be the best use of your time.
> There are other c implementations out there.
>
> Best
>

> On Mon, Dec 24, 2018 at 12:01 AM Alberto Barbaro via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>

> wrote:
>
> Hi,
> Could you keep us posted, or at least me? I'm interested to compile glibc as well and obtain the bitcode.
>
> Would you consider to use https://www.musl-libc.org in the meantime?
>
> Thanks
>

> On Sun, Dec 23, 2018, 12:00 Kristina Brooks via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>

> >> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>

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

> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>

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

> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

[David Jones via llvm-dev]

Is your only problem that you don't have definitions for mmap/ftruncate/mkdir?

If so, then you don't need to compile glibc. You merely need to solve the problem you actually have: you need a C library for your system calls.

I have no idea what operating system you are running on your target, but the function names suggest it's Unix-like. Unix-like operating systems typically implement system calls as a trap to the operating system using an instruction specially built for this purpose.  To this end, the "mmap" function in glibc merely arranges to get the arguments in the correct registers (or possibly the stack), and then invokes the proper trap.  Perhaps 10 lines of assembly in all.

If you can figure out the calling convention for your system calls, then you can easily write your own syscall library in assembler, for each call you require, which you can then link in, in addition to whatever else you are using.

[xuruobin via llvm-dev]

Since I'm working on clang4.0.1, I cannot use GRTE. I will try to extract these syscalls from glibc source code, thanks anyway.

> -----邮件原件-----
> 发件人: Kristina Brooks [mailto:nots...@gmail.com]
> 发送时间: 2018年12月23日 19:00
> 收件人: xuruobin <xuru...@huawei.com>
> 抄送: llvm...@lists.llvm.org
> 主题: Re: [llvm-dev] How to compile glibc with clang/llvm?