DWARF Information not Used with Wildcards

[Mark Wielaard]

On Sun, 2018-04-22 at 22:44 +0200, Mark Wielaard wrote:
> On Sun, 2018-04-22 at 09:27 +0200, Torsten Polle wrote:
> > > 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“.
> 
> aha. good observation.
> 
> So, the DWFL_ASSERT apparently triggers because the function is
> accepted by dwflpp::function_entrypc(), but wasn't before, since it
> doesn't have a simple low_pc/high_pc range.
> 
> I think this is a latent bug because the function assumes the code
> range for a function is just one block, but functions could be split in
> multiple ranges (for example a compiler might put the "cold" part of a
> function somewhere else than the "hot" part of a function).
> 
> The assert seem bogus. The function really shouldn't get and compare
> against highpc. And everywhere this function checks "addr >= highpc" it
> really should call dwarf_haspc (&it->die, addr).

Could you try the attached patch or the prologue-hasp branch at
https://code.wildebeest.org/git/user/mjw/systemtap/
(untested, but does compile)

Thanks,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dwflpp-resolve_prologue_endings-should-use-dwarf_has.patch
Type: text/x-patch
Size: 3466 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20180422/7de48426/attachment.bin>