llvm dev - Dec 2008 - [LLVMdev] llvm ocaml bindings

(ccing llvmdev) Hi Ranjit! I only ported Chris's tutorial and Gordon
did the vast majority of the    bindings, so they deserve most of the
praise. I believe there are techniques for walking over the CFG. You
can load up code using Llvm_bitreader, use things like
Llvm.iter_globals, Llvm.iter_functions, and Llvm.iter_instrs to walk
over the module, and write out a new llmodule using Llvm_bitwriter. Is
there something more specific you want to do?

On Mon, Dec 29, 2008 at 6:05 PM, Ranjit Jhala <jhala at cs.ucsd.edu>
wrote:
> Hi Erick --
>
> many thanks for writing the ocaml bindings and tutorial for LLVM !
>
> I had a question: i see there are bindings for _generating_ code, but are
> there also bindings for _reading_ code (e.g. visitors that go over CFG do
> different things depending on the kinds of instructions ?)
>
> Thanks!,
>
> -Ranjit.
>
>

Hi,


thanks Chris and Gordon for the fantasic infrastructure and ocaml 
bindings and Erick for the prompt response!

I'm looking to use LLVM to write program analyses for
C/C++ programs, but to use Ocaml to write the analyses.
I did see there were bindings for iterating over:

* functions    in a module	[iter_functions]
* basic blocks in a functions	[iter_blocks]
* instructions in a block	[iter_instrs]

The other things that i'd like are to know what kind of
instruction a given instruction was.

That is,

(a) some ML encoding of the different opcodes like
 	Instruction::Ret:
        	Instruction::Invoke:
        	Instruction::Call:
        	Instruction::Malloc:
        	Instruction::Alloca:
 	etc.
     e.g. encoded as an Ocaml type "llinstr" ?

(b) ML bindings for functions like Instruction::getOpcode
     e.g. functions like
         val instr_of_value : llvalue -> llinstr
 	val value_is_instr : llvalue -> bool
 	etc.

Are these available somewhere ?

Even if they are not, I am happy to try to add these bindings ...

Thanks!,

-Ranjit.

> (ccing llvmdev) Hi Ranjit! I only ported Chris's tutorial and Gordon
> did the vast majority of the    bindings, so they deserve most of the
> praise. I believe there are techniques for walking over the CFG. You
> can load up code using Llvm_bitreader, use things like
> Llvm.iter_globals, Llvm.iter_functions, and Llvm.iter_instrs to walk
> over the module, and write out a new llmodule using Llvm_bitwriter. Is
> there something more specific you want to do?
>
> On Mon, Dec 29, 2008 at 6:05 PM, Ranjit Jhala <jhala at cs.ucsd.edu>
wrote:
>> Hi Erick --
>>
>> many thanks for writing the ocaml bindings and tutorial for LLVM !
>>
>> I had a question: i see there are bindings for _generating_ code, but
are
>> there also bindings for _reading_ code (e.g. visitors that go over CFG
do
>> different things depending on the kinds of instructions ?)
>>
>> Thanks!,
>>
>> -Ranjit.
>>
>>
>

On 2008-12-30, at 21:07, Ranjit Jhala wrote:
> thanks Chris and Gordon for the fantasic infrastructure and ocaml
> bindings and Erick for the prompt response!
>
> I'm looking to use LLVM to write program analyses for
> C/C++ programs, but to use Ocaml to write the analyses.
> I did see there were bindings for iterating over:
>
> * functions    in a module	[iter_functions]
> * basic blocks in a functions	[iter_blocks]
> * instructions in a block	[iter_instrs]
>
> The other things that i'd like are to know what kind of
> instruction a given instruction was.
Hi Ranjit,

There are recently aded C bindings for the "isa<>" template
(actually,
dyn_cast_or_null<>), which is usually the preferred manner to access  
the type ID. There are no corresponding ocaml bindings yet. I think  
this is the most important missing feature for what you've described;  
most of the instruction properties have getters and setters.

Re exposing the type ID as an Ocaml variant type, consider that there  
is no type ID for Instruction, since it is abstract; matching an  
instruction would therefore be extremely inconvenient, and would be  
brittle with respect to additions or changes to the Value class  
hierarchy.
> llinstr

Adding Ocaml types for each llvm::Value class seems inadvisable to me.  
You can certainly try it, but I expect the result would be unusably  
cumbersome.

— Gordon