[PATCH] libdw: Make dwarf_getfuncs find all (defining) DW_TAG_subprogram DIEs.

Josh Stone jistone at redhat.com
Sat Sep 21 01:49:49 UTC 2013


On 09/20/2013 06:55 AM, Mark Wielaard wrote:
> Hi Josh,
> 
> 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

> stap -vl 'process("/usr/bin/stap").function("*")'
> old-eu: 34613 probe(s), 293796virt/94812res/12848shr/84688data kb, in 580usr/20sys/601real ms.
> new-eu: 75713 probe(s), 405508virt/175636res/13120shr/196372data kb, in 1610usr/40sys/1649real ms.
> mine: 75713 probe(s), 426504virt/196700res/13136shr/217368data kb, in 1530usr/40sys/1570real ms.

> stap -vl 'process("/usr/bin/stap").function("main")'
> 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 ms.
> 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?
(kernel-debuginfo-3.10.11-200.fc19.x86_64)

> stap -vl 'kernel.function("*")'
> old-eu: 97588 probe(s), 556896virt/326000res/105412shr/223176data kb, in 3040usr/80sys/3128real ms.
> new-eu: 97588 probe(s), 552236virt/321392res/105436shr/218488data kb, in 3490usr/90sys/3583real ms.
> mine: 97588 probe(s), 619132virt/388240res/105448shr/285384data kb, in 3300usr/100sys/3402real ms.

> stap -vl syscall.open
> old-eu: 2 probe(s), 398600virt/162556res/100152shr/62776data kb, in 450usr/20sys/470real ms.
> new-eu: 2 probe(s), 394272virt/158604res/100544shr/58416data kb, in 960usr/20sys/980real ms.
> mine: 2 probe(s), 476192virt/240440res/100544shr/140336data kb, in 1140usr/20sys/1167real ms.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stap-no-dwarf_getfuncs.patch
Type: text/x-patch
Size: 10428 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/elfutils-devel/attachments/20130920/8d46c90f/attachment-0001.bin>


More information about the elfutils-devel mailing list