[Bug translator/16161] New: Multiple address problems with symtab functions

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16161

            Bug ID: 16161
           Summary: Multiple address problems with symtab functions
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

I found several intertwined issues with functions resolved from
query_module_symtab.  We may want to break this into separate bugs, but to
begin with, they're easily described together.

> $ stap --vp 02 -l 'process("/usr/lib64/dyninst/libdyninstAPI.so").function("*LivenessAnalyzer*")'
> focused on module '/usr/lib64/dyninst/libdyninstAPI.so.8.1.2' = [0x3f23410000-0x3f2388eb18, bias 0 file /usr/lib/debug/usr/lib64/dyninst/libdyninstAPI.so.8.1.2.debug ELF machine |x86_64 (code 62)
> probe ~LivenessAnalyzer@../../dataflowAPI/h/liveness.h:55 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0xdbcb1
> probe _ZN16LivenessAnalyzer5queryEN7Dyninst8ParseAPI8LocationENS_4TypeERN5boost14dynamic_bitsetImSaImEEE@:-1 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0x0
> probe _ZN16LivenessAnalyzer8getIndexEN7Dyninst12MachRegisterE@:-1 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0x0
> probe _ZN16LivenessAnalyzerC1Ei@:-1 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0x0
> probe _ZN16LivenessAnalyzerD1Ev@:-1 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0x3f234ebcb0
> probe _ZN16LivenessAnalyzerD2Ev@:-1 process=/usr/lib64/dyninst/libdyninstAPI.so.8.1.2 reloc=.dynamic pc=0x3f234ebcb0
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("_ZN16LivenessAnalyzer5queryEN7Dyninst8ParseAPI8LocationENS_4TypeERN5boost14dynamic_bitsetImSaImEEE")
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("_ZN16LivenessAnalyzer8getIndexEN7Dyninst12MachRegisterE")
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("_ZN16LivenessAnalyzerC1Ei")
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("_ZN16LivenessAnalyzerD1Ev")
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("_ZN16LivenessAnalyzerD2Ev")
> process("/usr/lib64/dyninst/libdyninstAPI.so.8.1.2").function("~LivenessAnalyzer@../../dataflowAPI/h/liveness.h:55")

The "~LivenessAnalyzer" probe is the only one derived from debuginfo, with its
unmangled name and proper @file:line info.  Each "_Z*@:-1" came from the symbol
table.  Here's an excerpt from that table:

> $ nm -D /usr/lib64/dyninst/libdyninstAPI.so | grep LivenessAnalyzer
>                  U _ZN16LivenessAnalyzer5queryEN7Dyninst8ParseAPI8LocationENS_4TypeERN5boost14dynamic_bitsetImSaImEEE
>                  U _ZN16LivenessAnalyzer8getIndexEN7Dyninst12MachRegisterE
>                  U _ZN16LivenessAnalyzerC1Ei
> 0000003f234dbcb0 W _ZN16LivenessAnalyzerD1Ev
> 0000003f234dbcb0 W _ZN16LivenessAnalyzerD2Ev

Now the list of bugs:

(1) The 'U' undefined symbols should not have been used at all, nevermind with
a fake pc=0x0.

(2) The 'W' weak symbols are fine to use, but the address needs to lose the
prelinked location.  However, you can also see it's off by 0x10000 from what nm
reported, so this isn't just a prelink issue, and indeed "prelink -u" doesn't
fix this.  The address we found is actually related to the address where dwfl
loaded it, seen in that "focused on module" line.  There is a symbias available
from dwfl_module_info() which seems to be the fixup we'll want.

(3) Symbols at duplicate addresses were reported as separate probes in both (1)
and (2), which shouldn't happen within a single query.  In query_dwarf_func()
we track the set alias_dupes for functions, and symtab functions should
check/add that too.

(4) Those weak symbols happen to be duplicates of the debuginfo
"~LivenessAnalyzer" anyway.  I think alias_dupes may do the right thing once
the symbias is fixed though.  It looks a little tricky here since there's also
prologue searching, resolving it 1 byte later at 0xdbcb1, but I think this
shift happens after alias_dupes is checked.

(5) For most debuginfo symbols, we call update_symtab to set DIE info, which
makes it so query_module_symtab wouldn't have even considered that function at
all.  This failed here because the unmangled name is not in the symbol table,
so we didn't realize the relationship automatically.  This problem is actually
commented in update_symtab already, but I mention it again since it reared its
ugly head here.


Here's another test case that exhibits the bias issues, which got me down this
road, and it won't be fixed by simply ridding aliases and undefined symbols.

> $ stap --vp 02 -l 'process("/usr/lib64/libGL.so").function("*glClear")'
> focused on module '/usr/lib64/libGL.so' = [0x10000-0x26d1d0, bias 0 file /usr/lib/debug/usr/lib64/libGL.so.1.2.0.debug ELF machine |x86_64 (code 62)
> probe __indirect_glClear@/usr/src/debug/mesa-20130919/src/glx/indirect.c:2517 process=/usr/lib64/libGL.so reloc=.dynamic pc=0x22d00
> probe glClear@:-1 process=/usr/lib64/libGL.so reloc=.dynamic pc=0x52f80
> process("/usr/lib64/libGL.so").function("__indirect_glClear@/usr/src/debug/mesa-20130919/src/glx/indirect.c:2517")
> process("/usr/lib64/libGL.so").function("glClear")

> $ nm -D /usr/lib64/libGL.so | grep glClear$
> 0000000000042f80 T glClear

This one is "interesting" in that glClear is an ASM stub (without debuginfo)
which calls the internal function.  The 0x10000 offset is visible here, as
52f80 is past the end of .text, but nm shows it should have been 42f80.

-- 
You are receiving this mail because:
You are the assignee for the bug.