Hi,

I have a simple patch attached to improve the output addr2line -fi.  The
problem I had is it failed to identify the parent function name if there
was any lexical_block in the scope hierarchy.  For example, try the
following, compiled as the attached testfile-lex-inlines.bz2:

  1 // g++ x.cpp -g -fPIC -olibx.so -shared -O3 -fvisibility=hidden
  2
  3 void foobar()
  4 {
  5   __asm__ ( "nop" ::: );
  6 }
  7
  8 void foo()
  9 {
 10   {
 11     void (*bar) () = foobar;
 12     bar();
 13   }
 14 }

$ eu-addr2line -f -i -e testfile-lex-inlines.bz2 0x690
foobar inlined at /tmp/x.cpp:12 in _Z3foov
/tmp/x.cpp:9
??
/tmp/x.cpp:12

With my patch:

$ ./src/addr2line -fi -e testfile-lex-inlines.bz2 0x690
foobar inlined at /tmp/x.cpp:12 in _Z3foov
/tmp/x.cpp:9
_Z3foov
/tmp/x.cpp:12

So the name is resolved, and I'm happier.  But, as I went to make this a
testcase, I noticed that the ":9" line isn't really correct for "foobar"
-- that's the start of "foo".

There are two candidate lines for 0x690:
 [    33] special opcode 246: address+16 = +0x690 <_Z3foov>, line+4 = 9
 [    34] special opcode 14: address+0 = +0x690 <_Z3foov>, line-4 = 5

So what happens AFAICT, the name is found with dwarf_getscopes(), which
will find the innermost address match.  The line is found with
dwfl_module_getsrc, which uses a binary search, making no guarantees if
there are multiple matches.  The bsearch happened to pick the first one
in this case.  Perhaps this should choose the last matching address to
be approximately innermost?

I also noticed that addr2line's print_dwarf_function() doesn't try to
read linkage_name, although that wouldn't matter for this foobar inline.
 It also looks like it's trying to walk up the inline / subprogram
stack, but since dwarf_getscopes chases the abstract_origin, it doesn't
have any of that.  So print_dwarf_function() returns false, and it falls
back to dwfl_module_addrname to get the outer name.

With dwarf_getscopes_die this would work, including multiple layers of
inlines, as it later does for -i.  But actually, I think having -i makes
this "inlined at ..." message redundant.  Binutils addr2line -fi doesn't
print anything like this.  Should we just kill that part?

Patch review and other thoughts appreciated...

Josh