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

[Robinson, Paul]

Ø  4) pointer size - it's specified by the CU header, but not in the line table header

(beats head on table) gotta have that to interpret DW_LNE_set_address correctly, afaict that's the *only* reason .debug_line would need it.  Feh. But basically you always need that, just to get started.


Ø  5) inlining info

For conjuring up fake frames in the traceback, presumably?  That sort of thing always felt like the debugger was lying to me, personally.
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Wednesday, April 29, 2015 3:33 PM
To: Robinson, Paul
Cc: Greg Clayton; Eric Christopher; Eric Christopher; David Blaikie; Alexey Samsonov; cfe-dev at cs.uiuc.edu Developers
Subject: Re: [cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces



On Wed, Apr 29, 2015 at 3:23 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu<mailto:cfe-dev-bounces at cs.uiuc.edu> [mailto:cfe-dev-bounces at cs.uiuc.edu<mailto:cfe-dev-bounces at cs.uiuc.edu>] On
> Behalf Of Greg Clayton
> Sent: Wednesday, April 29, 2015 1:55 PM
> To: Eric Christopher
> Cc: Eric Christopher; Alexey Samsonov; David Blaikie; cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
> Developers
> Subject: Re: [cfe-dev] rfc: Adding a mode to -gline-tables-only to include
> parameter names, namespaces
>
> 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.

Hmmm why was that, again?  I can think of three possibilities, none of
which should be insurmountable:
1) CU has the base directory and filename of the compilation; .debug_line
can include these directly, if we know it's -gline-tables-only.
2) CU has the use_utf8 flag; just assume UTF-8.
3) CU points to the chunk of .debug_line for this CU; we can probably
work out how to reliably subdivide .debug_line without that assist.

I don't think (3) is an issue - the line tables probably have their length in them.

4) pointer size - it's specified by the CU header, but not in the line table header
5) inlining info (this is pretty much the major point/issue with -gmlt) is not included in the line table. Cary's two-level line tables address this, though it's not implemented in LLVM. It's the minimal debug_info describing function inlining that's what confuses LLDB.

- David


Thanks,
--paulr

>
> More comments inline below.
>
> > On Apr 29, 2015, at 12:47 PM, Eric Christopher <echristo at gmail.com<mailto:echristo at gmail.com>>
> wrote:
> >
> >
> >
> > On Wed, Apr 29, 2015 at 12:41 PM Nico Weber <thakis at chromium.org<mailto:thakis at chromium.org>> wrote:
> > On Wed, Apr 29, 2015 at 12:35 PM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote:
> > On Wed, Apr 29, 2015 at 12:25 PM, Nico Weber <thakis at chromium.org<mailto: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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto: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/ea93a83e/attachment.html>