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

[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