2016-07-26 53 views
5

Używam clang-3.5 do szczęśliwie zbudować wersje bitcode musl libc i użyć wyniku, aby produkować ładne samodzielne pliki wykonywalne.clang-3.8 i kompilator-rt vs libgcc

Ostatnie próby z clang-3.8 nie były tak szczęśliwe. Wydaje się, że bitcode clang-3.8 generuje używa funkcji zdefiniowanych w

compiler-rt/lib/builtins 

Typowymi przykładami funkcji Uważam zanieczyszczających bitcode są mulxc3, mulsc3 i muldc3. Mogę to rozwiązać, łącząc się z libgcc lub nawet z alternatywą dla llvm, gdybym miał jakąkolwiek jasność co to było. Chociaż wolałbym raczej zapobiec temu problemowi w pierwszej kolejności.

Widziałem wzmiankę o flagach takich jak rtlib=compiler-rt itp., Ale znalazłem cenną małą dokumentację na ten temat.

Oto kilka prostych pytań.

  1. Czy to możliwe, aby zapobiec clang z użyciem compiler-rt/lib/builtins w emitowanym bitcode? Lub jeśli nie

  2. Czy llvm produkuje wersję libgcc, które mogłem użyć. Właściwie mógłbym prawdopodobnie zbudować wersję bitcode, ale to poza tym.

Uwielbiam słuchać wskazówek na ten temat.

Dodane 08.12.2016: Więc będę zilustrować moje problemy z konkretnym workflow że ludzie mogą rozmnażać, jeśli chcą, albo, co bardziej prawdopodobne, po prostu skieruj się, gdzie jestem głupi.

Więc zacznij od sprawdzenia się:

musllv

i postępuj zgodnie z instrukcjami zawartymi w README.to kompilacji (tu używam dzyń-3.8 na ubuntu 14.04)

WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM 
make 
cd lib 
extract-bc -b libc.a 

będziesz również potrzebujesz bitu z prostego pliku wykonywalnego. Użyję tutaj nweb.c.

wllvm nweb.c -o nweb 
extract-bc nweb 

Teraz możemy robić takie rzeczy jak:

clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb 

Ten obieg idzie gładko brzękiem-3.5, ale dla brzękiem-3.8 otrzymujemy:

clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb 
/tmp/libc-f734a3.o: In function `cpowl': 
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3' 
/tmp/libc-f734a3.o: In function `cpowf': 
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3' 
/tmp/libc-f734a3.o: In function `csqrt': 
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3' 
/tmp/libc-f734a3.o: In function `cpow': 
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3' 
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation) 

Tak jak wskazuje @ Paul Brannan moglibyśmy spróbować

clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb 

Ale to gdzie ja prawdopodobnie głupi, bo otrzymujemy:

clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt' 

bez względu na to, czy używam go jako flagi łączącej lub kompilującej.

+0

Nie znam odpowiedzi na to pytanie, ale uważam, że ten raport o błędzie jest istotny: https://llvm.org/bugs/show_bug.cgi?id=16404 BTW, łączenie za pomocą --rtlib = compiler-rt rozwiązał moje problemy z łączeniem, szukając __muloti4, podczas gdy linkowanie z libgcc nie działało. –

+0

Dzięki za cynk @ paul-brannan, wygląda "can-o-wormish". Mimo to wydaje mi się, że nie dotykam Midasa. Wezwę obserwację, aby ludzie mogli zduplikować mój problem i zaprowadzili mnie do obiecanej ziemi. –

+0

Dodaję to tutaj, ponieważ chociaż nie odpowiada na moje pytanie, wydaje się również istotne. [Twórz pliki GNU wolne od klangów] (https://blogs.gentoo.org/gsoc2016-native-clang/2016/05/31/build-gnu-free-executables-with-clang/) –

Odpowiedz

0

OK, więc w końcu udało się zrobić postęp w tej sprawie. Zbudowałem llvm-3.8.1 wraz z projektem compiler-rt przy użyciu wllvm i wllvm++.

Jednym z produktów Build libclang_rt.builtins-x86_64.a, i od tego archiwum udało mi się wyodrębnić moduł bitcode

libclang_rt.builtins-x86_64.bc

za pomocą polecenia: extract-bc -b libclang_rt.builtins-x86_64.a Ten moduł bitcode ma definicje te brzydkie instrinsics jak __mulxc3, __mulsc3 i __muldc3.

Alleluja!