llvm dev - Dec 2008 - [LLVMdev] How to correlate LLVA with native ISA

Hi,

 How to correlate the LLVM IR-leve instructions and memory values
 with the machine instructions and memory locations?

 For example, if CMP instruction in machine ISA is selected for the ICMP
instruction in LLVA,
 with the Instruction datastructure for ICMP, is it possible to get the
memory address of CMP instruction? Assume that the code segment base address
is given.

 Similarly, by implementing an LLVM IR-level pass, is it feasible to get
the runtime memory address
 of a LLVM IR-level variable in global area? Assume the data segment base
address is given.

 In the LLVM library, there are already some classes starting with Machine
but I was not able to find
 any existing methods that would give the above information.

 Thanks in advance.

 Best,
 Keun Soo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081208/e08b8846/attachment.html>

Keun Soo Yim wrote:
>  
>  Hi,
>  
>  How to correlate the LLVM IR-leve instructions and memory values
>  with the machine instructions and memory locations?
Can you tell us what goal you are trying to accomplish that requires you 
to do this?  There might be better ways of doing what you want.

The answer to your question probably depends on whether you're trying to 
write a pure LLVM analysis/transform, a JIT, or can interpose at the 
static code generator.
>  
>  For example, if CMP instruction in machine ISA is selected for 
> the ICMP instruction in LLVA,
>  with the Instruction datastructure for ICMP, is it possible to get 
> the memory address of CMP instruction? Assume that the code segment 
> base address is given.
 From working strictly with the LLVM IR, I don't believe this is 
possible.  There is no instruction that can give you the address of an 
LLVM instruction.  There are multiple reasons for this: first, it would 
allow one to write code that branches into the middle of basic blocks, 
making LLVM's analysis passes much more tedious to write.  Second, 
instructions may be expanded to multiple machine instructions or 
peephole optimized away into 0 instructions during code generation.

If you're willing to work with the LLVM static code generator or JIT 
infrastructure, then things might be different.  The code generator may 
have knowledge of the correlation between LLVM IR instructions and 
native code instructions; you may be able to enhance it to get the 
information you need.
>  
>  Similarly, by implementing an LLVM IR-level pass, is it feasible to 
> get the runtime memory address
>  of a LLVM IR-level variable in global area? Assume the data segment 
> base address is given.
You should be able to find the address of anything that is link-time 
accessible: these include externally visible global variables and 
externally visible functions.  The name of a global variable is its 
location in physical memory.  Memory allocated by alloca and malloc are 
also guaranteed to be "real" memory locations; the value of the alloca
or malloc is the location within real memory.

It's not possible, however, to get the address of an SSA virtual 
register.  The code generator is free to put these into spill locations 
on the stack or into physical machine registers; in fact, the code 
generator can put an SSA value into different registers at different 
points in the function.

You can do things like writing a transform that will take selected SSA 
registers and change them into alloca'ed or malloc'ed memory (or even 
global variables).  It will hurt performance, but it will allow you to 
get a pointer to the real memory location in which they're stored.
>  
>  In the LLVM library, there are already some classes starting with 
> Machine but I was not able to find
>  any existing methods that would give the above information.
These are used for code generation.  Again, you may be able to do more 
fancy things at (static or dynamic) code generation time, but in pure 
LLVM IR transforms, your options are somewhat limited.

-- John T.
>  
>  Thanks in advance.
>  
>  Best,
>  Keun Soo 
>  
>

Thank your for reply.

 The reason why these information are needed is that I am trying to extract
the program signature (e.g., control flow) out side of the binary.
Conventional compiler technique adds extra checking code into the target
source or target IR in an invasive manner. Since code generator combines the
added code with the original one, they don't need to correlate these two
information.

  It is being implemented as an LLVM analysis pass by using *
MachineFunctionPass*. If it is MachineBasicBlock or MachineInstruction, does
it possible to get the starting address of real basic block and the exact
(runtime) address of real instruction?

  Unlike the FunctionPass, my MachineFunctionPass gets an error when it is
loaded by opt. The class has constructor, virtfn, runOnMachineFunction,
getPassName, runOnFunction, and getAnalysisUsage methods where body parts of
all methods are empty. Does any have a similar problem?

Error opening '../../src/Release/lib/SWP.so':
../../src/Release/lib/SWP.so:
undefined symbol: _ZTIN4llvm19MachineFunctionPassE

(without virtfn() definition)
Error opening '../../src/Release/lib/SWP.so':
../../src/Release/lib/SWP.so:
undefined symbol: _ZN4llvm19MachineFunctionPass6virtfnEv

 Thanks in advance!
 - Keun Soo

On Mon, Dec 8, 2008 at 2:28 PM, John Criswell <criswell at uiuc.edu>
wrote:
> Can you tell us what goal you are trying to accomplish that requires you
> to do this?  There might be better ways of doing what you want.
>
> The answer to your question probably depends on whether you're trying
to
> write a pure LLVM analysis/transform, a JIT, or can interpose at the
> static code generator.
>
 From working strictly with the LLVM IR, I don't believe this
is
> possible.  There is no instruction that can give you the address of an
> LLVM instruction.  There are multiple reasons for this: first, it would
> allow one to write code that branches into the middle of basic blocks,
> making LLVM's analysis passes much more tedious to write.  Second,
> instructions may be expanded to multiple machine instructions or
> peephole optimized away into 0 instructions during code generation.
>
> If you're willing to work with the LLVM static code generator or JIT
> infrastructure, then things might be different.  The code generator may
> have knowledge of the correlation between LLVM IR instructions and
> native code instructions; you may be able to enhance it to get the
> information you need.
>
>
> >  Similarly, by implementing an LLVM IR-level pass, is it feasible to
> > get the runtime memory address
> >  of a LLVM IR-level variable in global area? Assume the data segment
> > base address is given.
> You should be able to find the address of anything that is link-time
> accessible: these include externally visible global variables and
> externally visible functions.  The name of a global variable is its
> location in physical memory.  Memory allocated by alloca and malloc are
> also guaranteed to be "real" memory locations; the value of the
alloca
> or malloc is the location within real memory.
>
> It's not possible, however, to get the address of an SSA virtual
> register.  The code generator is free to put these into spill locations
> on the stack or into physical machine registers; in fact, the code
> generator can put an SSA value into different registers at different
> points in the function.
>
> You can do things like writing a transform that will take selected SSA
> registers and change them into alloca'ed or malloc'ed memory (or
even
> global variables).  It will hurt performance, but it will allow you to
> get a pointer to the real memory location in which they're stored.
>
> >
> >  In the LLVM library, there are already some classes starting with
> > Machine but I was not able to find
> >  any existing methods that would give the above information.
> These are used for code generation.  Again, you may be able to do more
> fancy things at (static or dynamic) code generation time, but in pure
> LLVM IR transforms, your options are somewhat limited.
>
> -- John T.
>
> >
> >  Thanks in advance.
> >
> >  Best,
> >  Keun Soo
> >
> >
>
> _______________________________________________
> 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/20081214/ffeda2e4/attachment.html>