Re: [DynInst_API:] Removed createInstPointAtAddr

[Josh Stone <jistone@xxxxxxxxxx>]

On 04/13/2012 07:41 PM, Andrew Bernat wrote:
> On Apr 13, 2012, at 8:24 PM, Josh Stone wrote:
> 
>> This is related to the talk I gave at pdweek, "Scripted Introspection
>> with Dyninst".  So in SystemTap, we already have our own analysis to
>> find whatever function, label, static tracepoint, etc. that the user
>> wanted.  We compute that as basically an offset into the executable or
>> shared object.
> 
> Gotcha. I wasn't there due to baby :) 

A worthwhile excuse, congrats!
Though you only get to use that so many times... ;)

>> Then at runtime, I can figure out where that object was mapped to get
>> the final address, and I want to use that as an instrumentation point.
>> Calling createInstPointAtAddr seemed perfect for this, and appeared to
>> work well in most cases.  (A few consistently failed though, like the
>> libc:longjump tracepoint addresses.)
>>
>> I'll take a look at BPatch_basicBlock::findPoint, though my immediate
>> reaction is that I don't know what block the address is in.  If this is
>> straightforward to determine though, maybe that's fine.
> 
> If you don't mind it being slow, I can reimplement the
> createInstPointAtAddr interface and have it manually determine which
> basic block to use. That will require some disassembly to verify that
> the address is correct.

I imagine whatever slowness there is, would be even worse to do the same
from the outside, right?  I mean, roughly the same analysis needs to be
done either way.

We could narrow it down slightly by making something like
createInstPointAtAddr in the BPatch_object that I proposed.  I expect
this is the easiest piece to figure out though, so may be not much help.

> ... actually, it will return a vector of points, since there may be
> more than one matching function. But I can give you a similar
> interface. Does that work?

Why would there be multiple functions for an address - just for inline
instances?  In that case I would only want to probe once at that
address, for whatever variety of inline contexts that entails.  Is there
something else that causes multiples?

Josh