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

[Nico Weber]

On Wed, Apr 29, 2015 at 12:47 PM, Eric Christopher <echristo at gmail.com>
wrote:

>
>
> On Wed, Apr 29, 2015 at 12:41 PM Nico Weber <thakis at chromium.org> wrote:
>
>> On Wed, Apr 29, 2015 at 12:35 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>>> On Wed, 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?
>>>>
>>>> (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. 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.)
>>>>
>>>
>>> Is there some way to change the pipeline to use the mangled name stored
>>> in .symtab instead of the DW_AT_name in the DWARF? My understanding is that
>>> the sanitizers already do this.
>>>
>>
>> See "We can't easily use symbol names as they get stripped very early in
>> our pipeline." above – from what I understand, one machine does the build,
>> strips, runs dsymutil to get a .dSYM bundle, and then that is shipped to
>> the crash servers.
>>
>>
> (adding Greg for dsymutil issues, but I don't think there's much in the
> way of solving it)
>

(the rdar is 20695512)


> Parameter names is something we could probably add. I'd like to see the
> impact of it from a size perspective. I mean, next people will want
> locations of parameters. Then... and we're right back to just full debug
> info.
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150429/6074f49b/attachment.html>