[PATCH] D147506: [DebugLine] save one debug line entry for empty prologue

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D147506#4362214 <https://reviews.llvm.org/D147506#4362214>, @smeenai wrote:

> This appears to break Godbolt's strategy for filtering code to only include your own functions. As a simple example, https://godbolt.org/z/6cbGeqc11 only displays the `ret`, whereas unchecking the filter for library functions (https://godbolt.org/z/qzGv7nGKq) displays the entire function. See https://github.com/compiler-explorer/compiler-explorer/issues/5020 and https://github.com/compiler-explorer/compiler-explorer/issues/5050 for more examples.
>
> For the code in my Godbolt link, we'd previously emit debug info like:
>
>   _Z1fOSt10shared_ptrIiE:                 # @_Z1fOSt10shared_ptrIiE
>   .Lfunc_begin0:
>           .file   15 "llvm-bisect/inputs" "godbolt-filtering.cpp" md5 0xa1c9e6751ece14286108589bebeb1200
>           .loc    15 3 0                          # llvm-bisect/inputs/godbolt-filtering.cpp:3:0
>           .cfi_startproc
>   # %bb.0:
>           #DEBUG_VALUE: f:sp <- $rdi
>           #DEBUG_VALUE: operator bool:this <- $rdi
>           .loc    2 1300 23 prologue_end          # /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/shared_ptr_base.h:1300:23
>           cmpq    $0, (%rdi)
>           setne   %al
>   .Ltmp0:
>           .loc    15 4 5                          # llvm-bisect/inputs/godbolt-filtering.cpp:4:5
>           retq
>
> So it was obvious that the function was associated with user code and not library code. We now emit the following debug info:
>
>   _Z1fOSt10shared_ptrIiE:                 # @_Z1fOSt10shared_ptrIiE
>   .Lfunc_begin0:
>           .cfi_startproc
>   # %bb.0:                                # %entry
>           #DEBUG_VALUE: f:sp <- $rdi
>           #DEBUG_VALUE: operator bool:this <- $rdi
>           .loc    2 1300 23 prologue_end          # /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/shared_ptr_base.h:1300:23
>           cmpq    $0, (%rdi)
>           setne   %al
>   .Ltmp0:
>           .file   15 "llvm-bisect/inputs" "godbolt-filtering.cpp" md5 0xa1c9e6751ece14286108589bebeb1200
>           .loc    15 4 5                          # llvm-bisect/inputs/godbolt-filtering.cpp:4:5
>           retq
>
> So the `retq` is the first place we see the association of the assembly with the user's input file, hence the truncated Godbolt output. How should Godbolt be handling the association of functions with user code (vs. library code) instead?

Better to discuss this here, or on one of those bugs?

In any case, what's godbolt doing - scanning the .debug_line table only? & checking the first entry related to the function symbol/label? If it could scan through the whole function's line table and check if any of the code came from the user's code, that might be an option? (though it could still end up detecting library functions - like templates that are instantiated with user defined types that then get inlined)

If you wanted to reliably detect functions defined in the user's source code, you'd have to use more than just the .debug_line section, you'd have to use the .debug_info section - Symbolizing just the starting address, then iterating up any stack frames you get (in case you get more than one, which would happen if the first instruction were inlined, for instance) and checking the function name/the file it's declared in is the file you're interested in.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147506/new/

https://reviews.llvm.org/D147506