clang-3.8 und compiler-rt vs libgcc

Question

Ich habe clang-3.5 verwendet, um glücklich zu bauen Bitcode-Versionen von Musl libc und verwenden Sie das Ergebnis, um schöne eigenständige ausführbare Dateien zu produzieren.

Jüngste Versuche mit clang-3.8 nicht so glücklich gewesen. Es scheint, dass die Bitcode clang-3.8 erzeugt Funktionen in

compiler-rt/lib/builtins 

Typische Beispiele für Funktionen definiert verwendet finde ich die Bitcode verschmutzen mulxc3, mulsc3 und muldc3. Ich kann das lösen, indem ich gegen libgcc oder sogar die llvm Alternative verbinde, wenn ich eine klare Vorstellung davon hatte, was das war. Obwohl ich das Problem lieber verhindern würde.

Ich habe erwähnt Fahnen wie rtlib=compiler-rt usw. gesehen, haben aber sehr wenig Dokumentation zu diesem Thema gefunden.

So, hier sind ein paar einfache Fragen.

1. Ist es möglich, zu verhindern clang im emittierten Bitcode die compiler-rt/lib/builtins verwenden? Oder wenn nicht

2. Hat llvm eine Version von libgcc produzieren, die ich verwenden könnte. Eigentlich würde ich wahrscheinlich eine Bitcode-Version davon bauen, aber das ist neben dem Punkt.

Liebe, einige Hinweise zu diesem Thema zu hören.

am 2016.12.08: Also werde ich meine Probleme mit einem bestimmten Workflow veranschaulicht, die Menschen reproduzieren können, wenn sie wollen, oder, was wahrscheinlicher ist, nur darauf hinweisen, wo ich dumm bin zu sein.

starten Also, indem Sie aus:

musllv

und die Anweisungen in der README.to folgen kompilieren (hier verwende ich Klirren-3.8 auf Ubuntu 14,04)

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

werden Sie benötige auch den Bitcode einer einfachen ausführbaren Datei. Ich werde nweb.c hier verwenden.

wllvm nweb.c -o nweb 
extract-bc nweb 

Jetzt können wir Dinge wie:

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

Dieser Workflow reibungslos verläuft für Klirren-3.5 aber für Klirren-3.8 erhalten wir:

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) 

So wie @ paul-brannan weist darauf hin, wir

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

könnten versuchen, aber das ist, wo ich wohl dumm bin zu sein, weil ich:

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

Unabhängig davon, ob ich es als Linking oder Compiling-Flag verwende.

Answer 1

OK, also habe ich es endlich geschafft, Fortschritte zu machen. Ich baute llvm-3.8.1 zusammen mit dem compiler-rt Projekt unter Verwendung wllvm und wllvm++.

Einer der Build-Produkte war libclang_rt.builtins-x86_64.a, und aus diesem Archiv konnte ich das Bitcode Modul

libclang_rt.builtins-x86_64.bc

mit dem Befehl extrahieren: extract-bc -b libclang_rt.builtins-x86_64.a Dieses Bitcode Modul hat Definitionen für diese nervigen instrinsics wie __mulxc3, __mulsc3 und __muldc3.

Halleluja!