[LLVMdev] How to correlate LLVA with native ISA

[Keun Soo Yim]

 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>