llvm dev - Jun 2017 - Building llvm with clang and lld on arm and the llvm arm backend relocation on position independent code

Hi,

I am trying to build a completely GNU free linux toolchain for the raspberry pi.

I successfully managed to compile llvm and clang for armv7 hard float ( both as
a cross compiler and as a native compiler ) together with the following:

Llvm with clang and lld
Clang builtins
Musl libc
libc++, libc++abi, libunwind

All works well with the only thing to notice being the need to use -fPIC in
order to access some library functions when my own c/c++ programs access those
functions.

The fact seems to be that musl libc exports some symbols as protected ( probably
correctly ) and lld ( probably correctly ) says it cannot preempt those symbols.
For this reason I seem to have to use -fPIC in the C and CXX flags but
everything seems to work ok.

Then I tried to use this compiler ( both the cross compiler and the native
compiler ) to compile llvm + clang + lld ( I want to have the toolchain built
with itself, again without any GNU software involved ) but when building the
clang executable I ran into the arm relocation problems mentioned here in the
“Hacks” section when using -fPIC:
http://llvm.org/docs/HowToCrossCompileLLVM.html
<http://llvm.org/docs/HowToCrossCompileLLVM.html> .
On the other hand, I seem to need -fPIC otherwise cmake fails to find some libc
functions such as futimes/futimens and many others. If I use -fPIC for CFLAGS
but not for CXXFLAGS then cmake finds those symbols but then obviously fails at
a later stage with lld unable to preempt those symbols.

This seems to be a conflict I cannot solve without someone within the llvm team
fixing the arm relocation problem. Is there any estimate of when this could
happen? I am happy to spend the time testing any solutions by building my own
toolchain until it succeeds. Or is there any other solution?

Thank you,
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170625/20e58fe9/attachment.html>

On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I am trying to build a completely GNU free linux toolchain for the
> raspberry pi.
>
> I successfully managed to compile llvm and clang for armv7 hard float (
> both as a cross compiler and as a native compiler ) together with the
> following:
>
> Llvm with clang and lld
> Clang builtins
> Musl libc
> libc++, libc++abi, libunwind
>
> All works well with the only thing to notice being the need to use -fPIC
> in order to access some library functions when my own c/c++ programs access
> those functions.
>
> The fact seems to be that musl libc exports some symbols as protected (
> probably correctly ) and lld ( probably correctly ) says it cannot preempt
> those symbols.
> For this reason I seem to have to use -fPIC in the C and CXX flags but
> everything seems to work ok.
>
Is this the same problem mentioned in
https://bugs.llvm.org/show_bug.cgi?id=32425?

> Then I tried to use this compiler ( both the cross compiler and the native
> compiler ) to compile llvm + clang + lld ( I want to have the toolchain
> built with itself, again without any GNU software involved ) but when
> building the clang executable I ran into the arm relocation problems
> mentioned here in the “Hacks” section when using -fPIC:
> http://llvm.org/docs/HowToCrossCompileLLVM.html .
> On the other hand, I seem to need -fPIC otherwise cmake fails to find some
> libc functions such as futimes/futimens and many others. If I use -fPIC for
> CFLAGS but not for CXXFLAGS then cmake finds those symbols but then
> obviously fails at a later stage with lld unable to preempt those symbols.
>
> This seems to be a conflict I cannot solve without someone within the llvm
> team fixing the arm relocation problem. Is there any estimate of when this
> could happen? I am happy to spend the time testing any solutions by
> building my own toolchain until it succeeds. Or is there any other
solution?
>
> Thank you,
> Alex
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170626/d45de33e/attachment.html>

> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote:
> 
> On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
> Hi,
> 
> I am trying to build a completely GNU free linux toolchain for the
raspberry pi.
> 
> I successfully managed to compile llvm and clang for armv7 hard float (
both as a cross compiler and as a native compiler ) together with the following:
> 
> Llvm with clang and lld
> Clang builtins
> Musl libc
> libc++, libc++abi, libunwind
> 
> All works well with the only thing to notice being the need to use -fPIC in
order to access some library functions when my own c/c++ programs access those
functions.
> 
> The fact seems to be that musl libc exports some symbols as protected (
probably correctly ) and lld ( probably correctly ) says it cannot preempt those
symbols.
> For this reason I seem to have to use -fPIC in the C and CXX flags but
everything seems to work ok.
> 
> Is this the same problem mentioned in
https://bugs.llvm.org/show_bug.cgi?id=32425?
<https://bugs.llvm.org/show_bug.cgi?id=32425?>
My aim is to build llvm+clang+lld using llvm+clang+lld on arm ( using musl,
libc++, libc++abi, libunwind and the clang builtins, no gcc runtime at all ).

I think the fact that lld cannot preempt some symbols without using -fPIC is
similar to the problem mentioned in https://bugs.llvm.org/show_bug.cgi?id=32425
<https://bugs.llvm.org/show_bug.cgi?id=32425> .

However I am not particularly bothered at this stage about having to use -fPIC.
That would be fine.

What I am struggling with is that having to use -fPIC is in conflict with the
arm backend issue that creates bad relocations when building clang with -fPIC as
mentioned in http://llvm.org/docs/HowToCrossCompileLLVM.html
<http://llvm.org/docs/HowToCrossCompileLLVM.html> and so the build with
-fPIC fails when building the clang binary.

Regarding https://bugs.llvm.org/show_bug.cgi?id=32425
<https://bugs.llvm.org/show_bug.cgi?id=32425> , please notice that
contrary to what is reported there I definitely can build and execute a C hello
world program without having to use -fPIC.

It is only some symbols from musl that cannot be preempted by lld, not all of
them.

Unfortunately, when building llvm+clang+lld quite a few of those symbols are
explicitly looked for by cmake and not found unless I use -fPIC.

If I go ahead and build without using -fPIC then the build fails because it
cannot preempt those symbols.

It looks like a paradox to me and I think the solution would be to fix the fact
that the arm backend does not like -fPIC as mentioned in
http://llvm.org/docs/HowToCrossCompileLLVM.html
<http://llvm.org/docs/HowToCrossCompileLLVM.html> . While it is probably
correct that lld says it cannot preempt protected symbols, the arm backend issue
is a known issue.
>  
> Then I tried to use this compiler ( both the cross compiler and the native
compiler ) to compile llvm + clang + lld ( I want to have the toolchain built
with itself, again without any GNU software involved ) but when building the
clang executable I ran into the arm relocation problems mentioned here in the
“Hacks” section when using -fPIC:
http://llvm.org/docs/HowToCrossCompileLLVM.html
<http://llvm.org/docs/HowToCrossCompileLLVM.html> .
> On the other hand, I seem to need -fPIC otherwise cmake fails to find some
libc functions such as futimes/futimens and many others. If I use -fPIC for
CFLAGS but not for CXXFLAGS then cmake finds those symbols but then obviously
fails at a later stage with lld unable to preempt those symbols.
> 
> This seems to be a conflict I cannot solve without someone within the llvm
team fixing the arm relocation problem. Is there any estimate of when this could
happen? I am happy to spend the time testing any solutions by building my own
toolchain until it succeeds. Or is there any other solution?
> 
> Thank you,
> Alex
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/7063f9f4/attachment.html>