Re: [DynInst_API:] Removed createInstPointAtAddr


Date: Wed, 25 Apr 2012 19:09:19 -0700
From: Josh Stone <jistone@xxxxxxxxxx>
Subject: Re: [DynInst_API:] Removed createInstPointAtAddr
On 04/25/2012 06:45 PM, Andrew Bernat wrote:
> On Apr 25, 2012, at 8:40 PM, Josh Stone wrote:
>> Actually, even the longjmp failure I had before looks a little better,
>> though it's still broken.  Before createInstPointAtAddr just gave NULL,
>> but with BPatch_image::createPointsAtAddr I get one point back in the
>> vector.  It still doesn't seem to execute instrumentation though.
>> Perhaps there's just something too weird about the way longjmp internals
>> work?  I'll keep this on my todo list to explore...
> 
> What's the longjmp failure? I don't recall, though I may have missed it. 

Sure - a slight background is that my test program is probing the
statically defined tracepoints (SDT) in libraries.  If you have a
current Fedora machine handy, try "readelf -n /lib64/libc-2.14.90.so" to
see an example of what's defined in .note.stapsdt.

Instrumenting most of these addresses under dyninst appears to work,
except for longjmp and longjmp_target.  I haven't done rigorous testing
on the rest, but they do fire.  But neither longjmp* works even in a
situation that I know should trigger it, which I can verify using stap's
normal kernel+uprobes instrumentation.

The old createInstPointAtAddr on 7.0 would just return NULL on the
longjmp addresses, so it was completely broken.

With your patch, BPatch_image::createPointsAtAddr appears to work on
longjmp, and insertSnippet on the one returned point also looks fine.
But in execution that ought to trigger the instrumentation, nothing happens.

>> Given how you implemented this at multiple levels, it may indeed make
>> sense to add a createPointsAtAddr in my BPatch_object patch as well.
>> [Still waiting for general feedback on that, nudge nudge ;)]
> 
> I was waiting on you and Bart working out license details. I think it's
> a clear "duh", actually, to have a file-level interface; it mirrors the
> internal interface much better than BPatch_module. 

Great - glad we agree. :)  Well when Bart is able to get to this, I'll
probably just connect him with our legal contact to sort out details.

Josh
[← Prev in Thread] Current Thread [Next in Thread→]