Tianwei <tianwei.sheng at gmail.com> writes:> someone suggested me to use gold-plugin, I know nothing about it yet, I will > have a try later. Does anyone have a good solution for this problem?Afaik gold does not help here. I tried it and managed to only generate native code. I'm currently investigating an alternative approach to produce whole-program bitcodes: 1) add /tmp/wrap to PATH 2) create /tmp/wrap/gcc with the following contents #!/bin/sh exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real ld and does not pass any unknown flags to it. With this approach I was able to compile and run airstrike (a 2d dogfighting game) in bitcode form very transparently with: $ make-bitcode fakeroot apt-get --build source airstrike $ sudo dpkg -i airstrike*.deb $ airstrike If you are interested I can try to rework my scripts to a shape where they could be used by somebody else. (*) I am not actually calling llvm-ld directly. Instead I have an "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to pack the resulting bitcode to a shell script that can execute itself with lli and use the correct -load options.
On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors <timo.lindfors at iki.fi> wrote:> Tianwei <tianwei.sheng at gmail.com> writes: >> someone suggested me to use gold-plugin, I know nothing about it yet, I will >> have a try later. Does anyone have a good solution for this problem? > > Afaik gold does not help here. I tried it and managed to only generate > native code."Just" gold isn't quite good enough, because at the last final link steps gold will still generate native code. However, it should be possible to find a way to get gold to leave the merged bitcode around somewhere, or perhaps do something like llvm-ld. Nicholas? The advantage of this approach is that it will potentially work with build systems that call ar/ld directly.> I'm currently investigating an alternative approach to produce > whole-program bitcodes: > > 1) add /tmp/wrap to PATH > 2) create /tmp/wrap/gcc with the following contents > > #!/bin/sh > exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" > > 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs > 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 > 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real > ld and does not pass any unknown flags to it. > > With this approach I was able to compile and run airstrike (a 2d > dogfighting game) in bitcode form very transparently with: > > $ make-bitcode fakeroot apt-get --build source airstrike > $ sudo dpkg -i airstrike*.deb > $ airstrikeVery clever though. :) - Daniel> If you are interested I can try to rework my scripts to a shape where > they could be used by somebody else. > > (*) I am not actually calling llvm-ld directly. Instead I have an > "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to > pack the resulting bitcode to a shell script that can execute itself with > lli and use the correct -load options. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Daniel Dunbar wrote:> On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors > <timo.lindfors at iki.fi> wrote: >> Tianwei <tianwei.sheng at gmail.com> writes: >>> someone suggested me to use gold-plugin, I know nothing about it yet, I will >>> have a try later. Does anyone have a good solution for this problem? >> Afaik gold does not help here. I tried it and managed to only generate >> native code. > > "Just" gold isn't quite good enough, because at the last final link > steps gold will still generate native code. However, it should be > possible to find a way to get gold to leave the merged bitcode around > somewhere, or perhaps do something like llvm-ld. Nicholas?It's easy. In gold-plugin.cpp all_symbols_read_hook() where lto_codegen_compile(cg, ...) is currently called, call lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. If someone were to rig this up to a command-line flag (search for LDPT_OPTION in the same file) then I would like to commit that change. Nick> The advantage of this approach is that it will potentially work with > build systems that call ar/ld directly. > >> I'm currently investigating an alternative approach to produce >> whole-program bitcodes: >> >> 1) add /tmp/wrap to PATH >> 2) create /tmp/wrap/gcc with the following contents >> >> #!/bin/sh >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" >> >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >> ld and does not pass any unknown flags to it. >> >> With this approach I was able to compile and run airstrike (a 2d >> dogfighting game) in bitcode form very transparently with: >> >> $ make-bitcode fakeroot apt-get --build source airstrike >> $ sudo dpkg -i airstrike*.deb >> $ airstrike > > Very clever though. :) > > - Daniel > >> If you are interested I can try to rework my scripts to a shape where >> they could be used by somebody else. >> >> (*) I am not actually calling llvm-ld directly. Instead I have an >> "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to >> pack the resulting bitcode to a shell script that can execute itself with >> lli and use the correct -load options. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >