Way to reproduce: 1. wget http://slonopotamus.org/libUE4Editor-Core.so (warning, 50MB) 2. ./src/addr2line -f -e libUE4Editor-Core.so 0x2c09b2 Expected output (as produced by addr2line from GNU binutils and I know that this is correct): _Z20PlatformCrashHandleriP9siginfo_tPv /home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp:595 Actual output (tested against commit e22cc80923f94e54c9384421904461958899db5b): _Z20PlatformCrashHandleriP9siginfo_tPv ??:0 So, function name is resolved correctly but filename/lineno info is missing.
Additional info on various addr2line implementations misbehaving on this testcase: https://github.com/gimli-rs/addr2line/issues/35#issue-213881844
gimli was fixed ( https://github.com/gimli-rs/addr2line/pull/36 ) and now is consistent with binutils (and llvm-symbolizer). I also sent a patch to elftoolchain so it also resolves filename/lineno properly (though not function name yet): https://sourceforge.net/p/elftoolchain/tickets/545/#6d97 gimpi problem was that they didn't handle DW_AT_MIPS_linkage_name and DW_AT_specification. elftoolchain problem was that they din't handle DW_AT_ranges for compile units (and only looked at lo/hi addresses). I suspect that you do not resolve filename/lineno properly for the same reason.
Dumping the whole decoded line table with eu-readelf --debug-dump=decodedline shows: /home/marat/production/ue4/Engine/Source/Runtime/Core/Private/Linux/LinuxPlatformCrashContext.cpp (mtime: 0, length: 0) 593:6 S 0 0 0 +0x00000000002c099f <_Z20PlatformCrashHandleriP9siginfo_tPv+0xef> 593:6 0 0 0 +0x00000000002c09ae <_Z20PlatformCrashHandleriP9siginfo_tPv+0xfe> 595:3 S 0 0 0 +0x00000000002c09b0 <_Z20PlatformCrashHandleriP9siginfo_tPv+0x100> 600:3 S 0 0 0 +0x00000000002c09b4 <_Z20PlatformCrashHandleriP9siginfo_tPv+0x104> 75:1 S 0 0 0 +0x00000000002c09b9 <_Z20PlatformCrashHandleriP9siginfo_tPv+0x109> 76:6 S 0 0 0 +0x00000000002c09be <_Z20PlatformCrashHandleriP9siginfo_tPv+0x10e> So there we are able to also deduce that address 0x2c09b2 is associated with LinuxPlatformCrashContext.cpp:595:3
Looking at the debug_info we do have: [39ca09] subprogram low_pc (addr) +0x00000000002c08b0 <_Z20PlatformCrashHandleriP9siginfo_tPv> high_pc (addr) +0x00000000002c0a05 lo_user+0x1fe7 (flag) Yes frame_base (block1) [ 0] reg7 MIPS_linkage_name (strp) "_Z20PlatformCrashHandleriP9siginfo_tPv" name (strp) "PlatformCrashHandler" decl_file (data1) 107 decl_line (data2) 580 external (flag) Yes lo_user+0x1fe1 (flag) Yes Which is inside a compile_unit generated by clang: [29d634] compile_unit producer (strp) "clang version 3.7.1 (tags/RELEASE_371/fi nal)" language (data2) C_plus_plus (4) name (strp) "-" stmt_list (data4) 581678 comp_dir (strp) "/home/marat/production/ue4/Engine/Source " lo_user+0x1fe1 (flag) Yes low_pc (addr) +000000000000000000 ranges (data4) range list [ c92e0] Note that the low_pc seems bogus (zero). And the range list seems bogus too (it consists of 800+ entries some of which look bogus too (+0x0000000000000001..+0x0000000000000001) and none seem to actually cover that function addresses. See also this discussion on the mailinglist: https://sourceware.org/ml/elfutils-devel/2017-q2/msg00190.html