Re: [DynInst_API:] Removed createInstPointAtAddr

[Josh Stone <jistone@xxxxxxxxxx>]

On 04/13/2012 06:29 PM, Andrew Bernat wrote:
> On Apr 13, 2012, at 5:34 PM, Josh Stone wrote:
>> That's a large commit, with changes in many places, but one of the 
>> casualties is createInstPointAtAddr.
>> 
>> I do not see that this was marked internal or deprecated, so was
>> the removal an accident?  Is there another function that can
>> achieve the same result?
> 
> 
> Yeah, that's my fault. We decided to outright remove it because the
> interface was dangerous; it's impossible to create an instPoint
> without specifying both a function and block, and that function
> didn't provide enough information. We hadn't decided what to replace
> it with at the time.
> 
> I have a function BPatch_basicBlock::findPoint(Address); I believe
> it's in git head but it's not in Dyninst 7.0. That's what you will
> want to use.
> 
> What are you trying to accomplish?

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.

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.

Thanks,
Josh