<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">My understanding of `always_inline` is that the attribute is meant to be used where not inlining a function would cause a (incorrect) change in semantics of the function (anything that uses certain builtins or inline assembly getting values of certain common registers like FP/SP/PC). Could it be worth adding another macro for the attribute that is less ambiguous in terms of whether forced inlining is a case of optimization, to distinguish it from uses (I'm not actually sure if there are any) where it may actually inadvertently change semantics?</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 15, 2018 at 8:02 PM Vedant Kumar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> On Dec 15, 2018, at 10:32 AM, Brian Gesiak via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hello all!<br>
> <br>
> I find that using lldb to debug LLVM libraries can be super<br>
> frustrating, because a lot of LLVM classes, like the constructor for<br>
> StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt<br>
> to have lldb evaluate an expression that implicitly instantiates a<br>
> StringRef, I get 'error: Couldn't lookup symbols:<br>
> __ZN4llvm9StringRefC1EPKc'.<br>
> <br>
> As an example, most recently this happened to me when playing around<br>
> with llvm::AttributeSet, having attached lldb to an opt built with<br>
> -DCMAKE_BUILD_TYPE="Debug":<br>
> <br>
>   (lldb) e $AS.hasAttribute("myattr")<br>
>   error: Couldn't lookup symbols:<br>
>     __ZN4llvm9StringRefC1EPKc<br>
> <br>
> Despite having built in a "Debug" configuration,<br>
> LLVM_ATTRIBUTE_ALWAYS_INLINE makes it very difficult to debug LLVM.<br>
> <br>
> How do you all deal with or work around this problem?<br>
<br>
I don't think there are any great workarounds. The data formatters in utils/lldbDataFormatters.py can help a bit.<br>
<br>
<br>
> Is there a good<br>
> way to do so? If not, would anyone object if I sent up a patch to<br>
> introduce a CMake variable or something to conditionally disable<br>
> LLVM_ATTRIBUTE_ALWAYS_INLINE? I'd like to be able to turn it off, but<br>
> I'm not sure if there's some good reason it needs to stay on even for<br>
> debug builds?<br>
<br>
IIRC the motivation for using always_inline in debug builds was to make binaries acceptably fast. IMHO this isn't the right tradeoff because it also makes binaries frustratingly hard to debug.<br>
<br>
Some might object that with clang modules, it should be no trouble for a debugger to evaluate these kinds of expressions. I've CC'd Raphael who can speak to this much better than I can. My understanding is that modules may help, but lldb (and presumably gdb as well?) are not going to learn how to parse templated code out of C++ modules, instantiate them, and JIT-compile them for you really soon. That seems like an ongoing, longer-term project.<br>
<br>
I'd like to see us move away from using always_inline in core ADT headers to make debugging easier in the near future.<br>
<br>
A note about slow Debug binaries. In my experience it's really never necessary have a separate Debug build tree. It takes up a slot of time/space and I've never found it useful. It's usually much more convenient to have a single RelAsserts build tree. If you need to debug code in some .cpp file, you can just:<br>
<br>
$ touch path/to/the/file.cpp<br>
$ export CCC_OVERRIDE_OPTIONS="+-g O0 +-UNDEBUG"<br>
$ ninja opt/clang/etc<br>
<br>
The build system will do an incremental recompile of the binary you want to debug, with the *single file* (or set of files) you care about recompiled with asserts, at -O0, with debug info. The resulting binary is pretty much just as fast as a RelAsserts binary and is perfectly debuggable, modulo always_inline functions ;)<br>
<br>
vedant<br>
<br>
<br>
> <br>
> - Brian Gesiak<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>