[cfe-dev] Make standalone-debug default based on glldb tuning
Adrian Prantl via cfe-dev
cfe-dev at lists.llvm.org
Fri Apr 12 11:09:31 PDT 2019
> On Apr 12, 2019, at 11:05 AM, paul.robinson at sony.com wrote:
>
>
>
>> -----Original Message-----
>> From: David Blaikie [mailto:dblaikie at gmail.com]
>> Sent: Friday, April 12, 2019 1:40 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 10:30 AM <paul.robinson at sony.com> wrote:
>>>
>>>
>>>
>>>> -----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.
>>>
>>
>> (bonus data: oh, apparently FreeBSD still defaults to GDB tuning - but
>> also want to opt-in to -fstandalone-debug so FreeBSD binaries are
>> usable with LLDB out of the box, even if it's not the default - and
>> they mention in ToolChains/FreeBSD.h that 'dtrace' has some issues
>> with this kind of DWARF too - non-specific as to what those issues
>> are)
>>
>>> 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?
>>
>> As I gave in the example/Adrian reiterated - it's cross-file (so
>> crossing a binary boundary, from one .so to another, for instance -
>> where the DWARF isn't merged across that boundary) rather than
>> cross-object, that's the issue.
>
> Building everything -fstandalone-debug still feels like it would be
> a big size hit to compensate for this, unless you also use type units.
> Which have their own size issues... but if LLDB is resisting the
> cross-loadfile fix, I guess it's a relatively small change to the
> compiler and users have the full set of options to undo it if they
> prefer.
I wouldn't necessarily phrase it as "LLDB is resisting the fix". AFAIK, thus far just nobody submitted a patch.
-- adrian
> --paulr
>
>>
>>> 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).
>>
>> I still think it's a significant inadequacy in LLDB & mentioned this
>> at the time it was discovered/worked around. But it's stuck around for
>> a while and means using -fno-standalone-debug with LLDB is not
>> practical on any platform. So tuning for LLDB should imply
>> -fstandalone-debug, which it currently doesn't.
>>
>> (that said, tuning for other debuggers shouldn't turn it off if a user
>> opted into it (eg: "-fstandalone-debug -ggdb" should still produce
>> standalone debug info) because there are other reasons (as the name
>> implies - if you're really only building a subset of objects with
>> debug info) you might have enabled it, so -ggdb shouldn't override
>> that choice)
>>
>> So my current proposed patch is quite small:
>>
>> - bool NeedFullDebug = Args.hasFlag(options::OPT_fstandalone_debug,
>> - options::OPT_fno_standalone_debug,
>> - TC.GetDefaultStandaloneDebug());
>> + bool NeedFullDebug = Args.hasFlag(
>> + options::OPT_fstandalone_debug, options::OPT_fno_standalone_debug,
>> + DebuggerTuning == llvm::DebuggerKind::LLDB ||
>> + TC.GetDefaultStandaloneDebug());
>>
>>> So I'm unconvinced that the basis of the -fstandalone-debug default
>>> should be changed.
>>
>> Seems reasonable to change the default when -glldb is specified, given
>> LLDB can't cope with that DWARF (& has made that an explicit choice
>> for years now). I still hope the bug will be addressed (likely as
>> Google starts to look at transitioning to LLDB but not wanting to take
>> the object size hit of disabling -fstandalone-debug).
>>
>>> 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.
>>
>> Have you considered shipping STL binaries with debug info? (that's
>> what I use on Ubuntu - there's separate -dbg variant packages for
>> libstdc++ that include the DWARF for the library) - GCC has the same
>> issue, though in a lesser form (it's not as aggressive as LLVM is -
>> for LLVM, it'll home/assume std::basic_string<char> (using an explicit
>> instantiation declaration/definition) is available elsewhere, GCC
>> won't - but both will assume that std::basic_ifstream<char> is 'homed'
>> (using the vtable location)).
>>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190412/dfea7224/attachment.html>
More information about the cfe-dev
mailing list