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

[David Blaikie via cfe-dev]

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.

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