(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.
|