On 05/15/2012 08:19 AM, Andrew Bernat wrote:
> And replying to myself again - do a pull and give
> "BPatch_object::fileOffsetToAddr" a try. It should do what you want.
Nice, that seems to work!
At least, that's the short answer. :) I am still fighting a few issues,
but I haven't root-caused them completely. I'll describe below in case
you can suggest anything.
I've started to publish my work in progress in a systemtap branch, in
case you want a reference of what I'm trying:
http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=shortlog;h=refs/heads/jistone/stapdyn
The code specifically using Dyninst is in the stapdyn directory. The
"dynsdt" program is a small standalone that I've been using to test the
SDT markers that I've been describing. The other "stapdyn" program is
for use by the whole systemtap client.
The SDT support actually has two pieces: the basic PC address, and an
optional data "semaphore" address that can be used to gate expensive
code around the probe address. (For example, libpython uses the
semaphore to avoid preparing string arguments for the probe if it's not
in use.) I discovered that it required more gymnastics than I thought
to turn the semaphore address into a file offset. The .note.stapsdt
section gives me data like this:
> stapsdt 70 Version: 3
> PC: 0xe0d3a, Base: 0x14b150, Semaphore: 0x3ae882
> Provider: python, Name: function__return, Args: '8@%rbx 8@%r13 -4@%eax'
> stapsdt 69 Version: 3
> PC: 0xe0f37, Base: 0x14b150, Semaphore: 0x3ae880
> Provider: python, Name: function__entry, Args: '8@%rbx 8@%r13 -4@%eax'
The Base is anchored to a compile-time section .stapsdt.base, so you can
compute where things are even after prelinking. So with these:
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flags Lk Inf Al
> [14] .stapsdt.base PROGBITS 0000003f0974b150 0014b150 00000001 0 A 0 0 1
> [25] .probes PROGBITS 0000003f099ae880 001ae880 00000004 0 WA 0 0 2
In this case the base didn't move, so the PC offset to file offset is
easy enough. The semaphore (in .probes) is trickier though, as I have
to figure out that the 0x3ae880 and 0x3ae882 addresses includes the
0x200000 padding between text and data, in order to get a file offset.
Well, I think I have this figured out into file offsets now, for use
with fileOffsetToAddr. But if you understood all that, perhaps you can
think of a different BPatch_object interface to convert those 0xe0d3a
and 0x3ae882 addresses into runtime addresses for instrumentation.
Even with that, it's not all peachy though, as I can't get the probes in
libpython to work -- the instrumentation never fires. At first I wasn't
changing the semaphore, so I thought that was the only issue. My new
snippet to poke the semaphore address appears to be doing the right
thing now, but the instrumentation still doesn't fire. I can get a
semaphore and probe test working in a small executable, just not libpython.
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...
Josh
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}