Re: [DynInst_API:] Correlating VariableLocation with Expression::Ptr

[Ashay Rane <ashay.rane@xxxxxxxxxx>]

Thanks Bill! Matching the _expression_ tree with the VariableLocation object was easy and I was able to get the job done.

On a side note, the Visitor interface didn't help much because I couldn't use it on the VariableLocation object. I tried constructing an _expression_ tree for a given VariableLocation object but the ResultTypes for the frameOffset or additions were not available. I had to build my own trees from either _expression_ objects or VariableLocation objects and write code to compare them. Quick question: Did I miss any DynInst APIs that can do this for me? It seems a bit cumbersome to require going through this alternative route.

Oh and yes, the debug information in optimized code is quite incomplete. The aliasing is not so much of an issue given the programs that I am dealing with.

Ashay

2014-07-14 11:22 GMT-05:00 Bill Williams <bill@xxxxxxxxxxx>:

On 07/12/2014 02:16 PM, Ashay Rane wrote:

Hello,

I am trying to limit the instructions that need to be instrumented
based on information from SymtabAPI. Using SymtabAPI, I have the
VariableLocation information like:

stClass: storageRegOffset, refClass: storageNoRef, mr_reg:
x86_64::rsp, frame_offset: fffffffffff159d8, low-pc: 0x4004f4,
high-pc: 0x4004f5

Using the BPatch interface, I have the _expression_::Ptr objects for
instructions that read/write memory.

How can I make sure that I instrument only those instructions for
which the operand address matches the VariableLocation? Is it
something that can be checked only a runtime? For instance, the
DynInstAPI Programmer's Guide shows a way to print effective address
of all load and store instructions. Will I (similarly) have to
instrument all load/store instructions and check whether the
instrumented address matches the VariableLocation? I fear that that
will substantially increase the overhead.

This depends largely on whether you are working in a domain where you can trust that the debug information is complete, correct, and that there are not aliased references to locals in a manner that's not defined by the DWARF information.

In that case, you can match up the elements of the _expression_ with elements of the local variable information. I would use the InstructionAPI Visitor interface to traverse an _expression_ and check it for equality/equivalence with the local variable location. And, of course, you can and should prune the locals you consider for each memory reference based on the PC for which they're valid.

If you have to worry about aliasing off stack pointer/frame pointer shenanigans, you can apply the stack analysis in DataflowAPI (note: this may also be a more efficient/effective way to match locals to memory references) and be reasonably certain that unless someone's being actively malicious we're catching all aliasing into the stack. If you have to worry about locals being aliased to god-knows-where, you're stuck verifying things at runtime but at that point you're also dealing with actively malicious debug information.

WRT stack analysis: for each instruction in the function, you can get the stack height of any register, which in turn can be used to label the instructions (and their memory references) with references to stack slots rather than arbitrary expressions. Those should, generally, be straightforward to compare to local variable locations (though again, the respective data structures don't know about each other). Possibly one of the students who's been working more actively with using stack analysis can chime in with more thoughts.

If there is any documentation on handling addresses where I can learn
how to make _expression_::Ptr work with the SymtabAPI, please let me
know. Thanks very much!

Ashay

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx