DWARF Information not Used with Wildcards

[Mark Wielaard]

Hi Torsten,

On Mon, 2018-04-09 at 22:32 +0200, Torsten Polle wrote:
> I’ve a problem with commit 5ef0c24456e3279cda2f444e9db0a3292388cdd7.

commit 5ef0c24456e3279cda2f444e9db0a3292388cdd7
Author: Mark Wielaard <mark@klomp.org>
Date:   Thu Feb 22 10:54:36 2018 +0100

    dwflpp::function_entrypc if entry or low pc isn't given use base or start.
    
    On Fedora rawhide a kernel compiled with GCC8 sometimes has subprograms
    without an entry or low pc attribute, but with a ranges attribute. In that
    case assume the base address or first start address of the range is the
    entry pc to set a probe on.

So that is mine. Sorry about that.

> When the commit is applied, the output of running the command
> (simplified)
> stap -L 'process("/lib64/libcarplay-plugin-
> core.so").function("*").call' | grep RTPJitterBufferRead
> yields
> process("/lib64/libcarplay-plugin-
> core.so").function("RTPJitterBufferRead").call
> 
> Seemingly, the DWARF information is ignored.
> 
> When I revert the commit and run the same command, I get the
> following output
> process("/lib64/libcarplay-plugin-core.so").function("RTPJitterBuffer
> Read@Sources/AirPlayUtils.c:1261").call $ctx:RTPJitterBufferContext*
> $inBuffer:void* $inLen:size_t
> 
> What’s strange is that 
> stap -L 'process("/lib64/libcarplay-plugin-
> core.so").function("RTPJitterBufferRead").call‘
> shows the correct output in both cases.

I haven't had time to replicate and study this yet. What is
/lib64/libcarplay-plugin-core.so?

But my guess is that we now erroneously pick up a function declaration
instead of a function definition.

Could you show the eu-readelf --debug-dump=info DIEs for the
RTPJitterBufferRead function in libcarplay-plugin-core.so?

Thanks,

Mark