[llvm-bugs] [Bug 43914] New: Aarch64 machine outliner results in imprecise stacktraces for outlined function calls

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43914

            Bug ID: 43914
           Summary: Aarch64 machine outliner results in imprecise
                    stacktraces for outlined function calls
           Product: tools
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: shuralnik at snapchat.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 22774
  --> https://bugs.llvm.org/attachment.cgi?id=22774&action=edit
Sample program

In some cases symbolication of stacktraces that contain locations of `bl
<OUTLINED_FUNCTION_xyz>` may incorrectly represent execution state.

Sample code is attached. I was using llvm toolchain from Android NDK r21 Beta
1.
Build command:

$
$ANDROID_NDK_R21/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang++
-shared -std=c++1z -flto -O2 -fuse-ld=lld -Wl,-mllvm
-Wl,-enable-machine-outliner=always -g outline.cc

Here is a piece of disassembled code for just built shared library:

 ...

000000000000128c <_Z3fooiii>:
    128c:       d10143ff        sub     sp, sp, #0x50
 ...
    12dc:       f9400ff3        ldr     x19, [sp,#24]
    12e0:       b24002c8        orr     x8, x22, #0x1
    12e4:       9400002a        bl      138c <OUTLINED_FUNCTION_0>
    12e8:       36000054        tbz     w20, #0, 12f0 <_Z3fooiii+0x64>

 ...

000000000000138c <OUTLINED_FUNCTION_0>:
    138c:       7200029f        tst     w20, #0x1
    1390:       9a930100        csel    x0, x8, x19, eq
    1394:       1400001f        b       1410 <puts at plt>

The OUTLINED_FUNCTION_0 basically performs some piece of std::string::c_str()
work and call to puts(). As result symbolicated address for a call to this
outlined function is next:

$ llvm-symbolizer-8 -e a.out 
0x12e4
std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>,
std::__ndk1::allocator<char> >::__get_pointer() const
/home/serhiihuralnik/tools/android-ndk-r21/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/string:1514:17
std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>,
std::__ndk1::allocator<char> >::data() const
/home/serhiihuralnik/tools/android-ndk-r21/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/string:1242:0
std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>,
std::__ndk1::allocator<char> >::c_str() const
/home/serhiihuralnik/tools/android-ndk-r21/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/c++/v1/string:1240:0
foo(int, int, int)
/home/serhiihuralnik/outline.cc:39:0

so far everything looks ok, but if we consider a complete stacktrace, with a
puts() frame above our code it becomes next:

#0 puts()
#1 __get_pointer()
#2 data()

and so on, which is read exactly like "__get_pointer() calls puts()
immediately". It is a nonsense of course. And also note that there is no frame
that corresponds to outlined function because is does a tail call.

Final result is that presence of a call to outlined function obscures an actual
location of where puts() is called from in terms of source code. 

This situation hurts debugging experience. Though in this particular example it
is easy to reconstruct proper stacktrace but in more complex scenarios (perhaps
with more complex outlined functions) this may be troublesome to manage
stacktraces that involve outlined code, making it harder to say to analyse
crashes where developer has no chances to reproduce issue by tracing it with
debugger.

As I understand a problem has two components:
 - the fact that outlined function may be used from different contexts where
the same instructions would map to different source code locations with no
clear way to encode all mappings and "mapping selectors" via DWARF
 - usage of tail calls in outlined functions, which hides this code from
unwinders

Is there any ways to improve such stacktraces except of turning outliner off?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191105/f90c963c/attachment.html>