[cfe-dev] Make standalone-debug default based on glldb tuning

[via cfe-dev]

> -----Original Message-----
> From: David Blaikie [mailto:dblaikie at gmail.com]
> Sent: Friday, April 12, 2019 12:43 PM
> To: Robinson, Paul
> Cc: Adrian Prantl; Clang Dev; Douglas Katzman
> Subject: Re: Make standalone-debug default based on glldb tuning
> 
> On Fri, Apr 12, 2019 at 9:38 AM <paul.robinson at sony.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: David Blaikie [mailto:dblaikie at gmail.com]
> > > Sent: Friday, April 12, 2019 12:06 PM
> > > To: Robinson, Paul
> > > Cc: Adrian Prantl; Clang Dev; Douglas Katzman
> > > Subject: Re: Make standalone-debug default based on glldb tuning
> > >
> > > On Fri, Apr 12, 2019 at 8:45 AM <paul.robinson at sony.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: aprantl at apple.com [mailto:aprantl at apple.com]
> > > > > Sent: Friday, April 12, 2019 11:21 AM
> > > > > To: David Blaikie
> > > > > Cc: Clang Dev; Robinson, Paul; Douglas Katzman
> > > > > Subject: Re: Make standalone-debug default based on glldb tuning
> > > > >
> > > > >
> > > > >
> > > > > > On Apr 12, 2019, at 8:18 AM, David Blaikie <dblaikie at gmail.com>
> > > wrote:
> > > > > >
> > > > > > I realized recently (as folks at Google have started
> experimenting
> > > > > > with LLDB) that the platform default for debugger tuning and the
> > > > > > default for -fstandalone-debug are both independent. This seems
> a
> > > bit
> > > > > > wrong to me because enabling -glldb doesn't enable -fstandalone-
> > > debug.
> > > > > >
> > > > > > I'm wondering if everyone's on board with removing
> > > > > > ToolChain::GetDefaultStandaloneDebug, and using
> > > > > > ToolChain::getDefaultDebuggerTuning() to select the default
> > > standalone
> > > > > > debug state?
> > > > > >
> > > > > > Then on the command line, I'd kind of expect one to override the
> > > > > > other, so things like "-glldb -fno-standalone-debug" is
> respected
> > > > > > (when it comes to hopefully fixing LLDB to cope with standalone
> > > debug
> > > > > > input).
> > > > > >
> > > > > > Sound good to everyone? If so I'll make a patch & send it for
> > > review.
> > > > > > (well, I'll probably work on the patch now anyway)
> > > > >
> > > > > Since this doesn't change anything for platforms that default to -
> > > glldb,
> > > > > I'm fine with this change.
> > > > >
> > > > > -- adrian
> > > >
> > > > I'm somewhat surprised LLDB would want -fstandalone-debug,
> independent
> > > > of the target.  It would be a source of unnecessary bloat on ELF-
> using
> > > > targets, no?
> > >
> > > LLDB fundamentally (at the moment) doesn't support -fstandalone-debug,
> > > no matter the file format.
> > >
> > > As far as I understand it: LLDB constructs ASTs from DWARF on a
> > > per-binary level (so, .so or executable). -fstandalone-debug creates
> > > "impossible" DWARF (eg: if one base class's vtable (& thus DWARF
> > > definition) is in one .so, but a derived class is in another .so -
> > > then the DWARF in the second .so contains a definition that derives
> > > from a declaration (& the DWARF consumer would have to go look in the
> > > other .so to stitch it up to a definition).
> >
> > Uh. Am I misunderstanding? Somehow I thought -fstandalone-debug meant
> > "full" which means the base class ought not to be a declaration in
> > the second .so?  Or is that pruning not based on the full/limited
> > distinction?
> 
> Sorry, I misspoke - the default ("no standalone debug") creates the
> DWARF that doesn't correspond to source in that you can see classes
> derived from declarations and the like. LLDB won't go searching for a
> definition that matches the declaration outside the scope of a single
> blob of DWARF (either a single object or single dsym, I guess).
> Turning on standalone debug avoids LLDB encountering these
> "impossible" situations.

Okay then! So the story is, LLDB doesn't want to chase after things
in other objects, which on Darwin is either expensive (in a .o case)
or moot (when dsymutil has done it all ahead of time).  Which leaves
me wondering about the ELF case; LLDB also doesn't want to troll 
through other CUs even when they are in the same executable?  That 
strikes me as a real inadequacy in LLDB, not something that the
compiler should compensate for. Especially once you upgrade to v5
and get the spiffy new index (thanks to Pavel).

So I'm unconvinced that the basis of the -fstandalone-debug default
should be changed.

FTR, I completely get the scenario Adrian describes where some
library has no debug info and the normal (limited) case fails to
provide a full definition. We've had complaints about not being
able to debug some STL-derived classes. Licensees are not too
happy about the extra size with the full-info workaround.
--paulr

> 
> >
> > >
> > > (FreeBSD defaults to -fstandalone-debug because it defaults to LLDB as
> > > the debugger - Adrian's reply makes me wonder if that's clear, so
> > > figured I'd mention that)
> > >
> > > > --paulr
> > > >
> > > >
> > > >