Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

On 05/16/2012 01:49 PM, Andrew Bernat wrote:
> On May 15, 2012, at 8:54 PM, Josh Stone wrote:
> 
>> Well, maybe it is odd after all.  Thanks to inlining, those libpython
>> probes end up as part of PyEval_EvalFrameEx(), a beast of a function
>> with several indirect jumps.  Disassembly attached^W available on request.
>>
>> Indeed, as it was with longjmp, BPatch_image::findFunction does locate
>> PyEval_EvalFrameEx, but findPoint(BPatch_entry) fails.
> 
> Yeah, probably uninstrumentable due to unparsed indirect jumps. 

Doesn't Dyninst have a fallback mode that uses traps?  Why can't that
work here?  i.e. plug in an int3 without having to move any code, and
run the instrumentation out of line in the trap handler.

>> That's a shame.  It seems that these SDT probes have a knack for showing
>> up in complicated code. :/
> 
> What, you want things to be easy???
> 
> Since BPatch_point is actually more general than
> instrumentation-only, perhaps we should add an "isInstrumentable"
> method that you can query.

Yes, this sounds like a good idea.

> Alternatively, the snippet insert could return an error, though that
> gets hard when you're using the "vector of points" interface.

With an isInstrumentable() method available to the caller beforehand,
this error becomes detectable and avoidable, so you could make it a full
error if any of the points vector can't be instrumented.  Perhaps make
this optional with an atomic flag, like finalizeInsertionSet's.

Josh