[clang] [clang][DebugInfo] Add inlined subprogram metadata for compiler built-ins (PR #189969)

[J. Ryan Stinnett via cfe-commits]

jryans wrote:

Thanks for taking a look @OCHyams. :smile: 

> I've not fully made up an opinion on this (which is partially why it's taken me a while to get to, sorry about they delay) - I think discussing it could help. (This is possibly this something that should be discussed on Discourse as although it doesn't seem too radical it does feels like a slightly "creative" use of DWARF?).

No worries, it's still a draft PR for the moment. (I am hoping to have it ready for review again quite soon.) 

In my opinion, the use of DWARF features here matches what the compiler is doing quite closely: a (built-in) function has been called by the source program and the compiler emits some behaviour where that call occurred. This work aims to wrap those places (that do not just become direct calls of identically-named library functions) in debug info that conveys what the compiler did: it "effectively" inlined the built-in's behaviour. Because there is no out-of-line function body for the called built-in (the compiler just injects the behaviour at the call site on demand), the called function is marked with `DW_AT_artificial` to convey the compiler-generated nature. 

This debug info treatment is similar to how Clang already represents implicitly declared functions (e.g. C++ implicit destructors), as well as trap and sanitiser function calls.

Perhaps let's try a round or two of answering questions as they arise here on the PR...? Of course, if anyone does feel strongly that a forum discussion is needed, we can certainly do so.

> - Macros are sort of a similar situation with substitution. I feel that classifying that sort of substitution as inlining would be misleading, where is the line? Does this really want a non-existent alternative DWARF feature instead?

In my opinion, treating these compiler built-in functions as if they were macro invocations is a bit too far away from what is happening. What we have here are calls to functions, but they just happen to be implemented in a slightly special way. An imaginary compiler might even actually have out-of-line functions for built-ins such as these. It just so happens that Clang "auto-inlines" the built-in function behaviour. To me, describing them as inlined functions is the closest match among existing DWARF features. It also seems quite close to the intended meaning of the DWARF features used. The `DW_AT_artificial` marker makes it clear that the function bodies do not actually exist on their own.

> - Out of curiosity what does GCC (or other compilers) do?

GCC appears to do roughly the same as Clang does before this PR: the built-ins that happen to emit normal calls see that portion described in debug info, but built-ins that may happen to emit behaviour directly at the call site (the category that is the focus of this PR) are not currently described in debug info.

> - Question about the impl, what source location do you use for the "inlined" instruction? If a user steps-in to one of these "inlined" functions, what does the debugger show/where do they "go"?

The built-in function calls are "inlined at" the call site, but then the built-in function bodies themselves have no source coordinates (recorded as line 0 in IR).

If you set a breakpoint on a call to one of these built-ins, the source code shown is the caller's code, since the built-in itself has no associated code. LLDB additionally emits a message "this address is compiler-generated code in function <name> that has no source code associated with it". The debugger does stop correctly at the beginning of the instruction range has described by the inlined subprogram DIE. The backtrace confirms you are inside the region of the built-in function's code. GDB behaves similarly.

So, I would say it presents a reasonable view in the debugger. While there is some value to this for interactive debugging, I would say there is greater value to other tools observing program behaviour, such as profilers, which can now account for time spent by these built-ins.

https://github.com/llvm/llvm-project/pull/189969