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 <b...@cs.wisc.edu>:

> 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@cs.wisc.edu
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
>>
>
> --
> --bw
>
> Bill Williams
> Paradyn Project
> b...@cs.wisc.edu
>
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Reply via email to