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

[Bill Williams <bill@xxxxxxxxxxx>]

On 07/15/2014 07:55 AM, Ashay Rane wrote:
> 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.
There are not APIs that will AST-ify VariableLocatons at present. (Food 
for thought, and an open question for the list: how should variable 
locations, instruction operands, stack heights, and existing snippet 
classes interoperate for better ease of use?) My thinking (such as it 
was) was that you could hand your Visitor a VariableLocation, and allow 
it to check off matching bits of the Expression as it visited them. 
Obviously, turning a VariableLocation into an AST and checking 
equivalence/equality that way will work as well.
> 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.
So I admit I'm curious: what's the big picture here? Obviously you want 
to match memory references to known local variables, but that's a 
partial solution to a whole host of problems, and there may be an easier 
way to get what you want out of Dyninst...
> Ashay
>
>
>
> 2014-07-14 11:22 GMT-05:00 Bill Williams <bill@xxxxxxxxxxx
> <mailto: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 <mailto:Dyninst-api@xxxxxxxxxxx>
>         https://lists.cs.wisc.edu/__mailman/listinfo/dyninst-api
>         <https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api>
>
>
>
>     --
>     --bw
>
>     Bill Williams
>     Paradyn Project
>     bill@xxxxxxxxxxx <mailto:bill@xxxxxxxxxxx>

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx