[cfe-dev] [lldb-dev] clang CL breaks LLDB std::string printing

[Vince Harron]

> 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 (I am working on this currently, <http://reviews.llvm.org/D7913>
should help, but apparently is not sufficient).

I couldn't get it working this way either.  Thanks for looking into this
Pavel!

> 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).

In most cases, I strongly prefer easy-of-use to completely optimal.  Even
if we fix splitdebug files, there is still the possibility of someone not
having debug symbols readily available or third party libraries without
symbols that we would like to support.  I recommend that we follow OSX and
FreeBSD and enable -fstandalone-debug by default on Linux and Android.

People who really know what they're doing can experiment with the
-fno-standalone-debug
and use it if it works for them.

Thoughts?

Vince



On Fri, Feb 27, 2015 at 6:12 AM, Pavel Labath <labath at google.com> wrote:

>
> On 26 February 2015 at 21:34, David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Wed, Feb 25, 2015 at 10:31 PM, Vince Harron <vharron at google.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> 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.
>>>
>>> I tracked it back to a clang CL that you submitted nearly a year ago.
>>>
>>> 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.
>>>
>>
>> Short answer is that you're probably missing the debug build of your
>> standard library (libstdc++-XXX-dbg).
>>
>> 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).
>>
>> 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.
>>
>> 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>.
>>
>> Hope that helps,
>>
>
> 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 (I am working on this currently, <http://reviews.llvm.org/D7913>
> should help, but apparently is not sufficient). 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). We could then probably
> disable it when testing splitdebug handling specifically.
>
> pl
>



-- 

Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150227/ea83d4b4/attachment.html>