[lldb-dev] test system, when using clang, flags

[jingham at apple.com]

> On Jul 9, 2014, at 11:34 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Wed, Jul 9, 2014 at 9:04 AM, Todd Fiala <tfiala at google.com> wrote:
> Hey all,
> 
> When running lldb tests with clang, on non-Apple platforms, we really need this flag set:
> -fstandalone-debug
> 
> We think this is a bug in LLDB, and would *really* like to see it fixed.  gdb works fine without this flag, and it *drastically* reduces the amount of debug info stored in object files.  My understanding is that the debug info that LLDB needs is there, but it's in a different compilation unit.
> 

I don't know what tests are failing, but very few of our tests have more than one file in them, and they don't tend to have very sophisticated classes in them.  I'd bet it has more to do with the fact that you have to be a little tricky when writing test cases to convince the compiler that you are really using stuff that you are defining just so you can test it.  If you don't do that right, the compiler outsmarts you and elides the debug info for the thing you're trying to test.  Rather than getting into an arms race with the compiler, it's far easier to just tell the compiler not to try to be smart about this.

BTW, lldb handles finding types from a compile unit that has the real definition and applying them to cases where they are only present as references in another compilation unit just fine.  I am pretty sure we even have tests for that.  If you have any cases where this is failing please file bugs about that.

The problems we've seen recently come when the compiler plays tricks like emitting some of the debug information for a class in a given compile unit, but eliding the debug information for one of the classes contained in that class because it thinks the sub-class isn't used.  That becomes kind of a nightmare because you now potentially have a whole array of "broken" class definitions in different compilation units where some or other of the contained class definitions are omitted, and the debugger has to figure out how to assemble the "best version" from the pieces.  Or you have to present different broken views of the class that don't contain the elided parts and make sure that never causes problems.  We don't do any of that work at present.

Jim


> Usually the missing information is type information about a class with a vtable where the first virtual method (aka the key function) is defined in a different TU.  That TU will emit the vtable and all type information for that class.
> 
> That said, it's fine if LLDB has to add the flag as a short-term way to stabilize the test suite.  I just want to make sure we're on the same page here: this is probably an LLDB bug, not a Clang bug.
>  
> It addresses issues where we end up missing complete debuginfo without it in some cases.  That ends up breaking the debugger's ability to perform some operations.  So, we're going to want that flag set when running tests on a host other than MacOSX.
> 
> We have a couple ways I suppose we can go about that: modify all the test build files to check if CC/CXX is clang, and add the symbol if so.  Or we can do something in the test framework build functions that tries to figure that out, and adds it if appropriate.
> 
> Any preferences on the way to handle this?
> -- 
> Todd Fiala |	 Software Engineer |	 tfiala at google.com |	 650-943-3180
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev