<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 3:12 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On 26 February 2015 at 21:34, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Wed, Feb 25, 2015 at 10:31 PM, Vince Harron <span dir="ltr"><<a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi David,<div><br></div><div>There are some LLDB tests that have been failing against clang-3.6 for a long time and just started failing in clang-3.5 when my Ubuntu distro updated clang-3.5.</div><div><br></div><div>I tracked it back to a clang CL that you submitted nearly a year ago.</div><div><br></div><div>This test passes when compiling with gcc 4.8.2 and clang-3.5 before this CL.  I'm very new to the project and I don't really understand what's going on here.  Any guidance you can offer would be very much appreciated.</div></div></blockquote></span><div><br>Short answer is that you're probably missing the debug build of your standard library (libstdc++-XXX-dbg).<br><br>Long answer: Compilers (both GCC & Clang) try to optimize debug info size by relying on the existence of debug info (especially for types) in other files. They use various signals to make this assumption - both Clang and GCC use vtables as one signal (if a type is dynamic, only emit the debug info for the definition of the type wherever the vtable is emitted). Beyond that, Clang also uses explicit template instantiation declarations as a signal as well (if there's an explicit template instantiation declaration, only emit the full definition of the type where the explicit instantiation definition is).<br><br>This allows the compilers to omit definitions in many cases, in favor of them being emitted in one or a small handful of places, reducing debug info size and linker input size.<br><br>In the case of std::basic_string<char>, libstdc++ (& other standard library implementations, I'd imagine) has an explicit instantiation declaration to avoid the compiler having to do all the work of instantiating basic_string<char> in every translation unit. The explicit instantiation definition is in the standard library objects (static or dynamic) and that's where the debug info for the type is. If you don't install the debug build of your standard library, you won't have the debug info definition of std::basic_string<char>.<br><br>Hope that helps,<br></div></blockquote></div><br></span>I'd like to add that simply installing libstdc++-dbg will not solve this problem currently as lldb has troubles loading symbols from splitdebug files</div></div></blockquote><div><br>What do you mean by splitdebug files? If you mean -gsplit-dwarf/Fission I'm not sure why that would be relevant - libstdc++-dbg isn't built with Fission so far as I know.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> (I am working on this currently, <<a href="http://reviews.llvm.org/D7913" target="_blank">http://reviews.llvm.org/D7913</a>> should help, but apparently is not sufficient). </div></div></blockquote><div><br>But, yes, there are bugs in LLDB specifically related to looking for definitions of certain types in certain contexts. The one I recall was hit when I first implemented this in clang was that LLDB expected a base class to have a definition in the CU it was referenced as a base class. The optimization caused that not to be the case - you could have a base class that was only declared, but defined in some other CU. LLDB was just failing to search other CUs for the definition as it is (presumably) already doing for normal declarations (one file has a "struct foo; foo *f;" and some other file has "struct foo { ... };" - when debugging the first file you reasonably expect to be able to, say, "p f->bar").<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">OTOH, adding -fstandalone-debug to C(XX)FLAGS does make the problem go away, and it could be something we might want to enable by default in test cases (to reduce dependencies on the test environment).</div></div></blockquote><div><br>I'm of several minds about test case design for debuggers/debug info.<br><br>LLVM takes a pretty hard line about writing isolated test cases, the equivalent to this for a debugger would be hardcoded DWARF (in assembly files, or possibly pre-compiled binaries with the source available). GDB has some tests like this, though they're hard to maintain, especially with Clang, due to the reordering of top level asm (hard to create the labels necessary to describe ranges when Clang might move the asm around).<br><br>The next most robust testing would be to at least make test cases standalone - don't include the platform's standard library, etc - have each test case define all the relevant constructs so there's no dependence on the platform's library implementation, ensuring tests are (more) portable.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> We could then probably disable it when testing splitdebug handling specifically.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">pl</div></font></span></div>
</blockquote></div><br></div></div>