Re: [DynInst_API:] BPatch_object

[Josh Stone <jistone@xxxxxxxxxx>]

(resending, as the list moderated my 374k disassembly attachment)

On 05/15/2012 05:50 PM, Josh Stone wrote:
> My only guess right now is that this is another silently-failing
> case, like the longjmp issue before.  These functions shouldn't have
> any oddities like that though.  More investigation required...

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.

That's a shame.  It seems that these SDT probes have a knack for showing
up in complicated code. :/

As before, I'd like to at least get an indication of this failure, if we
can't find a way to make it instrumentable(*).  I have an idea as a
workaround to try to look up the function entry for each address as a
feasibility test, but it would be nice to solve this error case at the
API level, as you mentioned before.

Thanks,
Josh


(*) If not fixable at the Dyninst level, this particular case could be
cheated by marking the functions in question with attribute noinline, so
they stay out of PyEval_EvalFrameEx.  They are already in the slow path,
so a forced call should be fine.