[cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces

[Nico Weber]

On Wed, Apr 29, 2015 at 1:33 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On Apr 29, 2015, at 1:30 PM, Nico Weber <thakis at chromium.org> wrote:
>
> On Wed, Apr 29, 2015 at 1:25 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Apr 29, 2015, at 1:03 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>
>>
>> On Apr 29, 2015, at 12:25 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>> Hi,
>>
>> the motivation for -gline-tables-only was to make debug info much
>> smaller, but still include enough to get usable stack frames [1]. We
>> recently tried using it in Chromium and discovered that the stack frames
>> aren't all that usable: Function parameters disappear, as do function
>> namespaces.
>>
>> Are there any concerns about adding a mode to -gline-tables-only (or a
>> second flag -gline-tables-full, or similar) that includes function
>> parameter info and namespace info but still omits most debug info?
>>
>>
>> I’m not convinced that the resulting debug info will dramatically smaller
>> than the full debug info. The largest bit of the debug info is the type
>> information if we are going to emit function parameters that will probably
>> pull in the majority of the types in the program.
>>
>>
>> (Background: We rely on dsym files to let our crash server symbolize
>> crash dumps we get from the wild. dsymutil uses debug info, but it
>> apparently crashes if debug info is > 4GB.
>>
>>
>> The problem here is that neither llvm nor dsymutil understand the 64-bit
>> DWARF format. Note that the llvm-dsymutil that is being developed will be
>> able to do ODR-based type uniquing for C++, which should also provide
>> enough savings to make this go well under the 4GB mark.
>>
>>
>> As a stopgap until all of Fred’s patches are in, you could also try
>> building with -fstandalone-debug.
>>
>
> Isn't that on by default on Darwin?
>
>
> It is of course. I meant to say -fno-standalone-debug.
>

Looks like this might do the trick for us, thanks! We'll try using this,
and if everything's happy with that flag we'll hope that by the time we hit
this again, dsymutil is more reliable. (fno-standalone-debug reduces dSYM
size from 4GB to 1.7GB, so this likely won't happen in the next few years.)


>
>
>
>> It will make LLDB unhappy but the result will still be much better than
>> 0-line-tables-only.
>>
>
>
>> -- adrian
>>
>>
>> We hit that recently. So we started using -gline-tables-only, but now all
>> our stacks are close to unusable, even though the motivation
>> for gline-tables-only was to still have usable stacks. We can't easily use
>> symbol names as they get stripped very early in our pipeline, and changing
>> that is apparently involved.)
>>
>>
>>
>> -- adrian
>>
>>
>> Thanks,
>> Nico
>>
>>
>> 1:
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120423/056674.html
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150429/c29f5ecf/attachment.html>