[LLVMdev] strace for whole-program bitcodes

[Paul Davey]

--emit-llvm??

On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov
<vkutuzov at accesssoftek.com>wrote:

> Hello everyone,
>
> I'm working on passing parameters for gold/LTO plug-in and could add this
> one as well.
> Just need an option name. Could anybody suggest one?
>
> Viktor
>
> ----- Original Message -----
> From: "Nick Lewycky" <nicholas at mxc.ca>
> To: "Daniel Dunbar" <daniel at zuster.org>
> Cc: "Kelly, Terence P (HP Labs Researcher)" <terence.p.kelly at hp.com>; <
> llvmdev at cs.uiuc.edu>
> Sent: Thursday, October 15, 2009 8:38 PM
> Subject: Re: [LLVMdev] strace for whole-program bitcodes
>
>
> 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
> >>
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091030/40e3ec41/attachment.html>