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

[Greg Clayton]

Actually parameters and their types and locations would greatly help out. This would increase debug info size, but it would also keep me from having to detect borked DWARF and having to avoid parsing any of it in LLDB. Right now the -gline-tables-only will quickly make LLDB assert and die if we try to use this debug info because we try to convert a function into a real clang::ASTContext type and clang will quickly assert and kill the debug session when it becomes unhappy with us trying to create functions with no params or return types (think "operator<" with no params... Boom. Crash).

It is too bad that DWARF requires compile units just so we can have line tables. If it wasn't for this, we could just emit a .debug_line section with no .debug_info.

More comments inline below.

> On 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?

I would like this due to reasons mentioned above.
> 
> (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.)

You can still recover function bounds using the LC_FUNCTION_STARTS load command even if you have a stripped executable. You won't have the function names, but you can still backtrace and you can get accurate function bound info for backtracing.

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

They probably just get the info from the symbol table.

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

It better strip _after_ you run dsymutil to make the dSYM or you will get empty dSYM files if the debug map is stripped. It really depends on what kind of strip you are doing.

> 
> 
> (adding Greg for dsymutil issues, but I don't think there's much in the way of solving it)
> 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.

My main issue with -gline-tables-only (which LLDB doesn't support currently due to the partial DWARF that is emitted that causes clang to assert and kill the debugger) is that we now have DWARF that we can't trust to use when creating types because all functions are potentially invalid to create in a clang::ASTContext since everything has been removed. Clang has the notion that certain types of functions must have certain number of arguments, like C++ operators, and it gets unhappy if we try to convert this DWARF into clang::AST types. We have a radar for clang to somehow mark the debug info has "-gline-tables-only" so we can know that any DW_TAG_subprogram tags we run into need to be converted to clang AST types that return "UnknownAnyTy" and taking varargs as the parameters so that they will be callable from the expression parser. We still might run into names that can't be used as function names, especially if the namespaces and class decl contexts are removed, so LLDB might have to just say "I am not parsing any DWARF from anything that had -gline-tables-only enabled..".

Greg Clayton