[LLVMdev] strace for whole-program bitcodes

[Guan Jun He]

any news?thanks

>>> "Guan Jun He" <gjhe at novell.com> 10/30/2009 2:22 PM >>>

--emit-llvm, if not conflict

>>> Paul Davey <plmdvy at gmail.com> 10/30/2009 11:11 AM >>>
--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/20091102/682aa890/attachment.html>