DWARF Information not Used with Wildcards

[Torsten Polle]

> Am 10.04.2018 um 16:37 schrieb Mark Wielaard <mark@klomp.org>:
> 
> 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

Hi Mark,

PFA the requested output. As the output is 31MB, I only provide an excerpt.

I tried to compare the output of a function which includes the full source path with the output of RTPJitterBufferRead. But I cannot find much of a difference.

Also I instrumented dwflpp::function_entrypc() it’s not even called. Still if I invalidate the patch by returning false after the first return true path (cf. dwflpp.cxx), dwflpp::function_entrypc() is called again (at least I see my log output) and the source file is shown again. I’m more than puzzled.

Regards,
Torsten
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dies-excerpt.txt
URL: <http://sourceware.org/pipermail/systemtap/attachments/20180410/1722cc71/attachment.txt>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwflpp.cxx
Type: application/octet-stream
Size: 865 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20180410/1722cc71/attachment.obj>