On 09/20/2013 06:55 AM, Mark Wielaard wrote:
On Thu, 2013-09-19 at 18:42 -0700, Josh Stone wrote:
> With systemtap-debuginfo-2.3-1.fc19.x86_64, my patched stap.git found
> 75713 probes in 'process("/usr/bin/stap").function("*")'
(as counted by
> the pass-2 -v line). Unpatched stap.git with your patched elfutils.git
> found only 61056 probes. :(
The attached patch fixes the partial/imported unit issue you found.
Which actually made the implementation simpler. I also added some
comments to the libdw.h dwarf_getfuncs documentation.
But it still doesn't seem to find as many probes as you do:
Pass 2: analyzed script: 72231 probe(s) [...]
Of course this does much more than just finding the defining
subprograms. So we might not be comparing the exact same thing. Could
you post you systemtap patch somewhere? I am just using the packaged
systemtap-2.3-1.fc19.x86_64 on itself with LD_LIBRARY_PATH pointing to a
elfutils git build with the below patch.
I think the apparent difference in your new patch is some oddity in
stap's git master. With your new patch for elfutils.git w/ stap-2.3, I
also get 72231, and w/ stap.git I get 75713.
The additions in stap.git look fishy. There are a lot with pc=0, which
shouldn't happen, like:
probe abort@@GLIBC_2.2.5@:-1 process=/usr/bin/stap reloc=.dynamic pc=0x0
Then some have no file:line info, but these might be fine, like:
probe _fini@:-1 process=/usr/bin/stap reloc=.dynamic pc=0x1edf14
But anyway, it doesn't appear to be an elfutils issue.
As requested, I attached my systemtap patch to bypass dwarf_getfuncs and
do our own full walk. It sometimes makes stap faster overall, but at
the cost of more memory (having preemptively cached more things). It
finds the exact same functions as your new dwarf_getfuncs.
Here are some (non-scientific) comparisons of time and memory use, with:
"old-eu" = systemtap.git and elfutils.git
"new-eu" = systemtap.git and elfutils.git with your patch
"mine" = systemtap.git with my patch and plain elfutils.git
old-eu: 34613 probe(s), 293796virt/94812res/12848shr/84688data kb, in
new-eu: 75713 probe(s), 405508virt/175636res/13120shr/196372data kb, in
mine: 75713 probe(s), 426504virt/196700res/13136shr/217368data kb, in
old-eu: 1 probe(s), 243908virt/45228res/10920shr/34800data kb, in 50usr/10sys/49real ms.
new-eu: 1 probe(s), 244344virt/47144res/12328shr/35208data kb, in 220usr/0sys/227real
mine: 1 probe(s), 270636virt/73208res/12336shr/61500data kb, in 240usr/10sys/249real ms.
So my patch saves a little time on the wildcard, loses in the specific
case, and uses a big chunk more memory either way. Of course, "old-eu"
doesn't find nearly as many probes for the wildcard, so it just shows
the cost of correctness here.
How about looking at the kernel?
stap -vl 'kernel.function("*")'
old-eu: 97588 probe(s), 556896virt/326000res/105412shr/223176data kb, in
new-eu: 97588 probe(s), 552236virt/321392res/105436shr/218488data kb, in
mine: 97588 probe(s), 619132virt/388240res/105448shr/285384data kb, in
stap -vl syscall.open
old-eu: 2 probe(s), 398600virt/162556res/100152shr/62776data kb, in 450usr/20sys/470real
new-eu: 2 probe(s), 394272virt/158604res/100544shr/58416data kb, in 960usr/20sys/980real
mine: 2 probe(s), 476192virt/240440res/100544shr/140336data kb, in 1140usr/20sys/1167real
Again, my patch has a slight time advantage on the wildcard, but loses
that on more specific probes, and uses much more memory. But this also
shows that the new dwarf_getfuncs slowed down about .5s either way, with
no benefit. Although, if we ever find a way to get the kernel using
partial units, we will need this anyway.
I'm not really inclined to commit my systemtap patch at this point - it
uses too much memory for inconsistent time gain/loss. Its only clear
advantage is that we don't have to wait for new elfutils. :P