Re: DWARF Information not Used with Wildcards

[Torsten Polle <Torsten dot Polle at gmx dot de>]

Hi Mark,

> Am 10.04.2018 um 22:40 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
> 
>> 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

I digged into this issue further.

The failure is caused by xpc_dictionary_create_compat() [1]. This function causes an exception at the following place:

dwflpp::resolve_prologue_endings()
{
  ...
  for(auto it = funcs.begin(); it != funcs.end(); it++)
    {
      Dwarf_Addr entrypc = it->entrypc;
      Dwarf_Addr highpc; // NB: highpc is exclusive: [entrypc,highpc)
      DWFL_ASSERT ("dwarf_highpc", dwarf_highpc (& it->die,
                                                 & highpc));
   ...
}

As a result of the exception query_cu() returns DWARF_CB_ABORT, which in turn makes dwflpp::iterate_over_cus<void>() bail out prematurely. Not all CUs are traversed, which includes the one that holds RTPJitterBufferRead().

Without the commit, dwflpp::function_entrypc() simply returns „bad“. With the commit, dwflpp::function_entrypc() returns „true“.

Kind Regards,
Torsten

[1] Excerpt for xpc_dictionary_create_compat

 [ a68a7]    subprogram
             external             (flag_present) 
             name                 (strp) "xpc_dictionary_create_compat"
             decl_file            (data1) 1
             decl_line            (data1) 107
             prototyped           (flag_present) 
             type                 (ref4) [ a5ba1]
             sibling              (ref4) [ a68d8]
 [ a68b6]      formal_parameter
               name                 (strp) "inKeys"
               decl_file            (data1) 1
               decl_line            (data1) 107
               type                 (ref4) [ a68d8]
 [ a68c1]      formal_parameter
               name                 (strp) "inValues"
               decl_file            (data1) 1
               decl_line            (data1) 107
               type                 (ref4) [ a68de]
 [ a68cc]      formal_parameter
               name                 (strp) "inCount"
               decl_file            (data1) 1
               decl_line            (data1) 107
               type                 (ref4) [ a52f6]
 [ a68d8]    pointer_type
             byte_size            (data1) 8
             type                 (ref4) [ a57a8]
 [ a68de]    pointer_type
             byte_size            (data1) 8
             type                 (ref4) [ a5bac]