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

2014-07-15 Thread Bill Williams 

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 mailto: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: fff159d8, 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 
ht

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

2014-07-15 Thread Ashay Rane 
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 :

> 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: fff159d8, 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

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

2014-07-14 Thread Bill Williams 

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: fff159d8, 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

[DynInst_API:] Correlating VariableLocation with Expression::Ptr

2014-07-14 Thread Ashay Rane 
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: fff159d8, 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.

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