LLVM bytecode simulator/emulator?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM bytecode simulator/emulator?

Kenneth.Hoste
Dear all,

Just today, I heard of the existence of the LLVM project. Because of its
high activity and projects, I'm quite interested in it for using it in
my research.
Currently, we are comparing applications/programs/benchmarks by
collecting characteristics of their dynamic behavior. This is done by
instrumenting the program (using ATOM on Alpha), and subsequently
running the program. During the instrumented run, anything we would like
to know about the dynamic behavior of the program is captured, and spit
out into log files.
The only drawback is that we are currently stuck to the Alpha
architecture, which means we are limited in our abilities... LLVM could
provide a solution to this, because the intermediar LLVM bytecode is not
biased towards a particular architecture. The question is if there are
tools to support the profilation of the benchmarks I'm running (i.e.
SPEC CPU2000, among others).

Are there any freely available instrumentator/simulator tools available
for the LLVM bytecode, which, if possible, are also properly maintained?
Or is there some kind of profilation already possbile, where I can start
from?

Any suggestions, remarks or ideas are welcome, either through replying
to the mailing list or to me directly.

greetings,

Kenneth Hoste
Phd student @ Ghent University


--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Wed, 12 Jul 2006, Kenneth Hoste wrote:
> Just today, I heard of the existence of the LLVM project. Because of its high
> activity and projects, I'm quite interested in it for using it in my
> research.
> Currently, we are comparing applications/programs/benchmarks by collecting
> characteristics of their dynamic behavior. This is done by instrumenting the
> program (using ATOM on Alpha), and subsequently running the program. During
> the instrumented run, anything we would like to know about the dynamic
> behavior of the program is captured, and spit out into log files.

ok.

> The only drawback is that we are currently stuck to the Alpha architecture,
> which means we are limited in our abilities... LLVM could provide a solution
> to this, because the intermediar LLVM bytecode is not biased towards a
> particular architecture.

Right.

> The question is if there are tools to support the
> profilation of the benchmarks I'm running (i.e. SPEC CPU2000, among others).

Yes. :)

> Are there any freely available instrumentator/simulator tools available for
> the LLVM bytecode, which, if possible, are also properly maintained? Or is
> there some kind of profilation already possbile, where I can start from?

There are two ways to do this.  The first is to instrument the LLVM
interpreter.  This is a matter of hacking on the functions in
lib/ExecutionEngine/Interpreter/Execution.cpp, and is very easy.

The other approach is to write an llvm-to-llvm instrumentation pass that
inserts code which dynamically computes (and logs) the properties you're
interested in.  This is how our profile information works, for example.

Hacking on the interpreter is easy, but has several drawbacks.  In
particular, the interpreter is very slow (even compared to other
interpreters) and it is missing functionality: you cannot call arbitrary
external functions, which causes many programs to fail in it.

OTOH, writing an llvm-to-llvm transformation has many advantages: we have
plenty of robust infrastructure for doing such a thing, many people use
this, you can use any code generator you like with it (JIT, static
compiler, or C backend), and you can even use LLVM optimizations to reduce
the cost of your instrumentation.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
Chris Lattner wrote:
> Hacking on the interpreter is easy, but has several drawbacks.  In
> particular, the interpreter is very slow (even compared to other
> interpreters) and it is missing functionality: you cannot call arbitrary
> external functions, which causes many programs to fail in it.

What do you mean by external functions? I only need to print stuff to
file, the measuring of the characteristics should be pretty easy I think.


> OTOH, writing an llvm-to-llvm transformation has many advantages: we
> have plenty of robust infrastructure for doing such a thing, many people
> use this, you can use any code generator you like with it (JIT, static
> compiler, or C backend), and you can even use LLVM optimizations to
> reduce the cost of your instrumentation.

Is there some kind of tutorial on this? Or an example program or
something? This sounds quite interesting...

Kenneth



--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Thu, 13 Jul 2006, Kenneth Hoste wrote:
> Chris Lattner wrote:
>> Hacking on the interpreter is easy, but has several drawbacks.  In
>> particular, the interpreter is very slow (even compared to other
>> interpreters) and it is missing functionality: you cannot call arbitrary
>> external functions, which causes many programs to fail in it.
>
> What do you mean by external functions? I only need to print stuff to file,
> the measuring of the characteristics should be pretty easy I think.

I mean things like printf, exit, write, etc.  Take a look at
lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp

If there is a small set of things you need to support, this shouldn't be a
problem.  Adding functions is easy.

>> OTOH, writing an llvm-to-llvm transformation has many advantages: we have
>> plenty of robust infrastructure for doing such a thing, many people use
>> this, you can use any code generator you like with it (JIT, static
>> compiler, or C backend), and you can even use LLVM optimizations to reduce
>> the cost of your instrumentation.
>
> Is there some kind of tutorial on this? Or an example program or something?
> This sounds quite interesting...

There is extensive documentation at http://llvm.org/docs/

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
Chris Lattner wrote:

> On Thu, 13 Jul 2006, Kenneth Hoste wrote:
>> Chris Lattner wrote:
>>> Hacking on the interpreter is easy, but has several drawbacks.  In
>>> particular, the interpreter is very slow (even compared to other
>>> interpreters) and it is missing functionality: you cannot call
>>> arbitrary external functions, which causes many programs to fail in it.
>>
>> What do you mean by external functions? I only need to print stuff to
>> file, the measuring of the characteristics should be pretty easy I think.
>
> I mean things like printf, exit, write, etc.  Take a look at
> lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp
>
> If there is a small set of things you need to support, this shouldn't be
> a problem.  Adding functions is easy.
>
>>> OTOH, writing an llvm-to-llvm transformation has many advantages: we
>>> have plenty of robust infrastructure for doing such a thing, many
>>> people use this, you can use any code generator you like with it
>>> (JIT, static compiler, or C backend), and you can even use LLVM
>>> optimizations to reduce the cost of your instrumentation.
>>
>> Is there some kind of tutorial on this? Or an example program or
>> something? This sounds quite interesting...
>
> There is extensive documentation at http://llvm.org/docs/

After browsing through the docs, at a first glance I think I should
write a plugin for the 'analyze' tool. I think
http://llvm.org/docs/WritingAnLLVMPass.html is where I should start from.
The only problem I see now is that there doesn't seem to be a way to get
information on a single instruction while being able to keep state over
all instructions... Is that possible, and if it is, can oyu tell me how
(or where I can find an example of it?).

greetings (and thanks for your help),

Kenneth



--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Thu, 13 Jul 2006, Kenneth Hoste wrote:
> After browsing through the docs, at a first glance I think I should write a
> plugin for the 'analyze' tool. I think
> http://llvm.org/docs/WritingAnLLVMPass.html is where I should start from.
> The only problem I see now is that there doesn't seem to be a way to get
> information on a single instruction while being able to keep state over all
> instructions... Is that possible, and if it is, can oyu tell me how (or where
> I can find an example of it?).

I don't really understand what you mean by this, but a ModulePass is fully
general, it can do anything.  Can you explain what you're trying to do?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
Chris Lattner wrote:

> On Thu, 13 Jul 2006, Kenneth Hoste wrote:
>> After browsing through the docs, at a first glance I think I should
>> write a plugin for the 'analyze' tool. I think
>> http://llvm.org/docs/WritingAnLLVMPass.html is where I should start from.
>> The only problem I see now is that there doesn't seem to be a way to
>> get information on a single instruction while being able to keep state
>> over all instructions... Is that possible, and if it is, can oyu tell
>> me how (or where I can find an example of it?).
>
> I don't really understand what you mean by this, but a ModulePass is
> fully general, it can do anything.  Can you explain what you're trying
> to do?

The way we're characterizing programs now, is adding our own code after
every instruction. When that instruction gets executed (which can happen
several times, for example inside a loop), we update our state. A simple
example is counting the number of dynamic instructions executed, or the
instruction mix (% loads, % stores, ...) in the dynamic execution.
If I was able to do that using LLVM, we would have characteristics on a
higher level of abstraction. The documentation on the BasicBlock pass
mentions not to keep state over different basic blocks, but I do want
that. Also, I need a way to iterate over the _dynamic_ instruction
stream. Is there a way to do that?

Example static vs dynamic:

static:
L: add x, y
    sub y, z
    jmpif z>100
    mul x, z

dynamic:
add x, y
sub y, z
jmpif z>100
add x, y
sub y, z
jmpif z>100
...
jmpif z>100
mul x, z


If my problem still isn't clear, it's because I didn't explain it well.
Feel free to ask further questions. I'll look into the
documentation/examples today, to see if I can find some kind of dynamic
analysis.

greetings,

Kennneth


--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Robert L. Bocchino Jr.
Hi,

I have done something like this.  I wrote a simple pass that instrumented LLVM instructions with external calls into a library of instrumentation functions (in my case, I was printing out a trace of dynamic load, store, and other data).  To analyze a program, I compiled the program to LLVM, ran the analyze pass on it, then linked the instrumented program with the library (also compiled to LLVM).  To generate the trace, I just ran the instrumented program.  For something very simple, like counting dynamic instructions, you could dispense with the library and modify the LLVM directly to do the following:  declare a static global counter, initialize it to zero in main, and increment it after every LLVM instruction in the original program.

Rob

On Jul 13, 2006, at 10:26 PM, Kenneth Hoste wrote:

Chris Lattner wrote:
On Thu, 13 Jul 2006, Kenneth Hoste wrote:
After browsing through the docs, at a first glance I think I should write a plugin for the 'analyze' tool. I think http://llvm.org/docs/WritingAnLLVMPass.html is where I should start from.
The only problem I see now is that there doesn't seem to be a way to get information on a single instruction while being able to keep state over all instructions... Is that possible, and if it is, can oyu tell me how (or where I can find an example of it?).
I don't really understand what you mean by this, but a ModulePass is fully general, it can do anything.  Can you explain what you're trying to do?

The way we're characterizing programs now, is adding our own code after every instruction. When that instruction gets executed (which can happen several times, for example inside a loop), we update our state. A simple example is counting the number of dynamic instructions executed, or the instruction mix (% loads, % stores, ...) in the dynamic execution.
If I was able to do that using LLVM, we would have characteristics on a higher level of abstraction. The documentation on the BasicBlock pass mentions not to keep state over different basic blocks, but I do want that. Also, I need a way to iterate over the _dynamic_ instruction stream. Is there a way to do that?

Example static vs dynamic:

static:
L: add x, y
   sub y, z
   jmpif z>100
   mul x, z

dynamic:
add x, y
sub y, z
jmpif z>100
add x, y
sub y, z
jmpif z>100
...
jmpif z>100
mul x, z


If my problem still isn't clear, it's because I didn't explain it well. Feel free to ask further questions. I'll look into the documentation/examples today, to see if I can find some kind of dynamic analysis.

greetings,

Kennneth


-- 
Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
_______________________________________________
LLVM Developers mailing list

Robert L. Bocchino Jr.

Ph.D. Student

University of Illinois, Urbana-Champaign



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

John Criswell
In reply to this post by Kenneth.Hoste
Kenneth Hoste wrote:

> Chris Lattner wrote:
>> On Thu, 13 Jul 2006, Kenneth Hoste wrote:
>>> After browsing through the docs, at a first glance I think I should
>>> write a plugin for the 'analyze' tool. I think
>>> http://llvm.org/docs/WritingAnLLVMPass.html is where I should start
>>> from.
>>> The only problem I see now is that there doesn't seem to be a way to
>>> get information on a single instruction while being able to keep
>>> state over all instructions... Is that possible, and if it is, can
>>> oyu tell me how (or where I can find an example of it?).
>>
>> I don't really understand what you mean by this, but a ModulePass is
>> fully general, it can do anything.  Can you explain what you're
>> trying to do?
>
> The way we're characterizing programs now, is adding our own code
> after every instruction. When that instruction gets executed (which
> can happen several times, for example inside a loop), we update our
> state. A simple example is counting the number of dynamic instructions
> executed, or the instruction mix (% loads, % stores, ...) in the
> dynamic execution.
Okay.  As Rob has already said, it sounds like you want to write an LLVM
pass that adds global variables and instructions to a program.  So, to
state it explicitly, you want to:

1) Compile the program that you want to instrument to LLVM bytecode
using llvm-gcc.
2) Use an LLVM pass that you write to instrument the program.
3) Use LLVM's llc program to generate C or assembly code of your
instrumented program.
4) Compile the C/asm code to native code with gcc and link it with any
native code libraries that it needs.
5) Run the program and gather the information from your instrumentation
instructions.

>
> If I was able to do that using LLVM, we would have characteristics on
> a higher level of abstraction. The documentation on the BasicBlock
> pass mentions not to keep state over different basic blocks, but I do
> want that. Also, I need a way to iterate over the _dynamic_
> instruction stream. Is there a way to do that?
I think you want to write a ModulePass instead of a BasicBlock pass.

A BasicBlockPass's runOnBasicBlock() method is called by the PassManager
for each basic block in the program.  Therefore, a BasicBlockPass cannot
calculate some piece of information while modifying one basic block and
use that information when modifying another basic block (i.e. it cannot
maintain state between invocations).

Since your instrumentation pass will need to add a global variable to
the program, a BasicBlockPass is not suitable for what you want to do.  
I would recommend using a ModulePass.  A ModulePass is given an entire
Module (i.e. an entire LLVM bytecode file).  Your pass can add a global
counter variable and then iterate over every instruction in the Module,
instrumenting it as needed.

-- John T.

>
> Example static vs dynamic:
>
> static:
> L: add x, y
>    sub y, z
>    jmpif z>100
>    mul x, z
>
> dynamic:
> add x, y
> sub y, z
> jmpif z>100
> add x, y
> sub y, z
> jmpif z>100
> ...
> jmpif z>100
> mul x, z
>
>
> If my problem still isn't clear, it's because I didn't explain it
> well. Feel free to ask further questions. I'll look into the
> documentation/examples today, to see if I can find some kind of
> dynamic analysis.
>
> greetings,
>
> Kennneth
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
John Criswell wrote:

> Okay.  As Rob has already said, it sounds like you want to write an LLVM
> pass that adds global variables and instructions to a program.  So, to
> state it explicitly, you want to:
>
> 1) Compile the program that you want to instrument to LLVM bytecode
> using llvm-gcc.
> 2) Use an LLVM pass that you write to instrument the program.
> 3) Use LLVM's llc program to generate C or assembly code of your
> instrumented program.
> 4) Compile the C/asm code to native code with gcc and link it with any
> native code libraries that it needs.
> 5) Run the program and gather the information from your instrumentation
> instructions.
>

That sounds indeed like what I want to do, but... I want the library
functions (for example printf), to be counted aswell. I.e., I don't make
any distinction between program code and library code. This is essential
for me, because I need the analysis of the program to predict/estimate
performance, and that's quite hard, if not impossible, without taking
the library count into account.

Is there a way to statically compile my program (along with the library
code) into a LLVM bytecode file? That way, I can just instrument that,
and go on from there with steps 3-5, ignoring the 'link with any native
code library'. The libraries I need are either pretty standard (i.e.
glibc), or I have the code for them (so I can compile it along with the
program).

Maybe it's possible using the lli interpreter (which is a lot slower, I
know), instead of the analyze tool?

> Since your instrumentation pass will need to add a global variable to
> the program, a BasicBlockPass is not suitable for what you want to do.  
> I would recommend using a ModulePass.  A ModulePass is given an entire
> Module (i.e. an entire LLVM bytecode file).  Your pass can add a global
> counter variable and then iterate over every instruction in the Module,
> instrumenting it as needed.

Okay, I get that... In ATOM, you're able to iterate over all basic
blocks, and inside each basic block iterate over all it's instructions,
and adding instrumentation code after each instruction that way. Hence
the confusion probably :)

Thanks!

Kenneth

--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Fri, 14 Jul 2006, Kenneth Hoste wrote:
> That sounds indeed like what I want to do, but... I want the library
> functions (for example printf), to be counted aswell. I.e., I don't make any
> distinction between program code and library code. This is essential for me,
> because I need the analysis of the program to predict/estimate performance,
> and that's quite hard, if not impossible, without taking the library count
> into account.

You can certainly do that.  First step is to find source for these
functions and compile them to LLVM bytecode.  Only once you do that can
you link the bytecode together.

> Maybe it's possible using the lli interpreter (which is a lot slower, I
> know), instead of the analyze tool?

No, they both have the same scope: all the code compiled to llvm bytecode.
Neither can inspect native system code.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
In reply to this post by Kenneth.Hoste
On Fri, 14 Jul 2006, Kenneth Hoste wrote:
>> I don't really understand what you mean by this, but a ModulePass is fully
>> general, it can do anything.  Can you explain what you're trying to do?
>
> The way we're characterizing programs now, is adding our own code after every
> instruction. When that instruction gets executed (which can happen several
> times, for example inside a loop), we update our state. A simple example is

Right.

> counting the number of dynamic instructions executed, or the instruction mix
> (% loads, % stores, ...) in the dynamic execution.
> If I was able to do that using LLVM, we would have characteristics on a
> higher level of abstraction. The documentation on the BasicBlock pass
> mentions not to keep state over different basic blocks, but I do want that.
> Also, I need a way to iterate over the _dynamic_ instruction stream. Is there
> a way to do that?

You can't iterate over dynamic instructions without running the program.
Optimization passes happen at compile time, not runtime.  If you want
information about the dynamic behavior of the program, either modify the
interpreter, or insert code that computes the properties you care about.

-Chris

> Example static vs dynamic:
>
> static:
> L: add x, y
>   sub y, z
>   jmpif z>100
>   mul x, z
>
> dynamic:
> add x, y
> sub y, z
> jmpif z>100
> add x, y
> sub y, z
> jmpif z>100
> ...
> jmpif z>100
> mul x, z
>
>
> If my problem still isn't clear, it's because I didn't explain it well. Feel
> free to ask further questions. I'll look into the documentation/examples
> today, to see if I can find some kind of dynamic analysis.
>
> greetings,
>
> Kennneth
>
>
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

John Criswell
In reply to this post by Kenneth.Hoste
Kenneth Hoste wrote:

> John Criswell wrote:
>> Okay.  As Rob has already said, it sounds like you want to write an
>> LLVM pass that adds global variables and instructions to a program.  
>> So, to state it explicitly, you want to:
>>
>> 1) Compile the program that you want to instrument to LLVM bytecode
>> using llvm-gcc.
>> 2) Use an LLVM pass that you write to instrument the program.
>> 3) Use LLVM's llc program to generate C or assembly code of your
>> instrumented program.
>> 4) Compile the C/asm code to native code with gcc and link it with
>> any native code libraries that it needs.
>> 5) Run the program and gather the information from your
>> instrumentation instructions.
>>
>
> That sounds indeed like what I want to do, but... I want the library
> functions (for example printf), to be counted aswell. I.e., I don't
> make any distinction between program code and library code. This is
> essential for me, because I need the analysis of the program to
> predict/estimate performance, and that's quite hard, if not
> impossible, without taking the library count into account.
>
> Is there a way to statically compile my program (along with the
> library code) into a LLVM bytecode file? That way, I can just
> instrument that, and go on from there with steps 3-5, ignoring the
> 'link with any native code library'. The libraries I need are either
> pretty standard (i.e. glibc), or I have the code for them (so I can
> compile it along with the program).
You can compile library code into LLVM bytecode libraries and link them
with gccld.  In general, LLVM provides tools equivalent to most of your
compiler tool chain (gccas, gccld, llvm-ar, llvm-nm, etc).  You can, for
example, make an archive of LLVM bytecode files.

The problem, in your case, is that no one has successfully compiled all
of libc into LLVM bytecode yet.  Some libc functions are compiled to
LLVM bytecode (see llvm/runtime), but many others are not; for those, we
link against the native libraries after code generation.

You can try compiling the parts of libc you need to LLVM bytecode, but
be forewarned that it'll be tedious.  C libraries (glibc in particular)
seem to be designed to make life difficult for people who want to
compile them.

-- John T.

>
>
> Maybe it's possible using the lli interpreter (which is a lot slower,
> I know), instead of the analyze tool?
>
>> Since your instrumentation pass will need to add a global variable to
>> the program, a BasicBlockPass is not suitable for what you want to
>> do.  I would recommend using a ModulePass.  A ModulePass is given an
>> entire Module (i.e. an entire LLVM bytecode file).  Your pass can add
>> a global counter variable and then iterate over every instruction in
>> the Module, instrumenting it as needed.
>
> Okay, I get that... In ATOM, you're able to iterate over all basic
> blocks, and inside each basic block iterate over all it's
> instructions, and adding instrumentation code after each instruction
> that way. Hence the confusion probably :)
>
> Thanks!
>
> Kenneth
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
John Criswell wrote:

> You can compile library code into LLVM bytecode libraries and link them
> with gccld.  In general, LLVM provides tools equivalent to most of your
> compiler tool chain (gccas, gccld, llvm-ar, llvm-nm, etc).  You can, for
> example, make an archive of LLVM bytecode files.
>
> The problem, in your case, is that no one has successfully compiled all
> of libc into LLVM bytecode yet.  Some libc functions are compiled to
> LLVM bytecode (see llvm/runtime), but many others are not; for those, we
> link against the native libraries after code generation.
>
> You can try compiling the parts of libc you need to LLVM bytecode, but
> be forewarned that it'll be tedious.  C libraries (glibc in particular)
> seem to be designed to make life difficult for people who want to
> compile them.

I think to amount of glibc functions I need to support will be limited.

We have some compiler experts in our research group, who will be able to
help me when I experience serious problems (I think).
I think it's worth a shot, atleast until I can really evaluate if the
effort is worth it or not.

Besides that, I can probably rely on the expierence of some people on
this mailinglist? What is the best way to start such an ambitious
project? Do I just check which external functions are called in the
bytecode I get, and try to support those functions using LLVM code?

Why has no-one supported printf yet? Is it that hard (I have no idea
really, I'm only asking)?

greetings, and thanks already for your replies

Kenneth

--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Fri, 14 Jul 2006, Kenneth Hoste wrote:
> Besides that, I can probably rely on the expierence of some people on this
> mailinglist?

You can always ask, but realize you are at the mercy of people's goodwill,
so you can't count on anything.  In practice, we try to help, but are
often very busy.

> What is the best way to start such an ambitious project? Do I
> just check which external functions are called in the bytecode I get, and try
> to support those functions using LLVM code?

llvm-dis < foo.bc | grep '^declare' will tell you all the external
functions.

> Why has no-one supported printf yet? Is it that hard (I have no idea really,
> I'm only asking)?

No one has needed it.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Kenneth.Hoste
Chris Lattner wrote:
> On Fri, 14 Jul 2006, Kenneth Hoste wrote:
>> Besides that, I can probably rely on the expierence of some people on
>> this mailinglist?
>
> You can always ask, but realize you are at the mercy of people's
> goodwill, so you can't count on anything.  In practice, we try to help,
> but are often very busy.

I understand, but any help I can get will be usefull I think. And, for
what it's worth, my work will help LLVM growing, right?

2 more questions which can get me started:

- Is there a particular version of glibc I should start from?
llvm/runtime doesn't mention any version numbers (or I must have missed
them).

- If I'm correct, supporting new glibc functions means adding an
implementation for them in llvm/runtime/GCCLibraries/libc/io.c (for
example). Currently, only 'puts' is supported there.
Only, in my current setup, the runtime libraries seem to be skipped:

konijn:~/work/LLVM/bin boegel$ make
Makefile:22: Skipping runtime libraries, llvm-gcc 4 detected.

Why is that? Can I fix this by changing my configuration?

>
>> What is the best way to start such an ambitious project? Do I just
>> check which external functions are called in the bytecode I get, and
>> try to support those functions using LLVM code?
>
> llvm-dis < foo.bc | grep '^declare' will tell you all the external
> functions.
>

OK, thanks.

>> Why has no-one supported printf yet? Is it that hard (I have no idea
>> really, I'm only asking)?
>
> No one has needed it.
>

Well, I guess other people will be able to benefit from it, if I get it
to work that is :)

Kenneth

--
Statistics are like a bikini. What they reveal is suggestive, but what
they conceal is vital (Aaron Levenstein)

Kenneth Hoste
ELIS - Ghent University
[hidden email]
http://www.elis.ugent.be/~kehoste
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM bytecode simulator/emulator?

Chris Lattner
On Fri, 14 Jul 2006, Kenneth Hoste wrote:

> Chris Lattner wrote:
>> On Fri, 14 Jul 2006, Kenneth Hoste wrote:
>>> Besides that, I can probably rely on the expierence of some people on this
>>> mailinglist?
>>
>> You can always ask, but realize you are at the mercy of people's goodwill,
>> so you can't count on anything.  In practice, we try to help, but are often
>> very busy.
>
> I understand, but any help I can get will be usefull I think. And, for what
> it's worth, my work will help LLVM growing, right?
>
> 2 more questions which can get me started:
>
> - Is there a particular version of glibc I should start from? llvm/runtime
> doesn't mention any version numbers (or I must have missed them).

You can use any implementation you want, it doesn't have to be glibc.
Maybe one of the 'tiny' libc implementations would serve your purposes
better.

> - If I'm correct, supporting new glibc functions means adding an
> implementation for them in llvm/runtime/GCCLibraries/libc/io.c (for example).
> Currently, only 'puts' is supported there.

Not necessarily, there is no need for you to integrate them into the llvm
build system.

> Only, in my current setup, the runtime libraries seem to be skipped:
> konijn:~/work/LLVM/bin boegel$ make
> Makefile:22: Skipping runtime libraries, llvm-gcc 4 detected.
>
> Why is that? Can I fix this by changing my configuration?

No.  llvm/runtime is specifically to support llvm-gcc3, and isn't used by
llvm-gcc4.  The goal isn't to provide parts of libc for "static linking",
the goal of that directory is to implement pieces of the runtime needed
for exception handling, etc, where we were not compatible with GCC.

When llvmgcc4 supports EH, it will use the standard GCC/system exception
handling libraries and ABI's.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev