[PATCH] Enable standalone-debug by default on FreeBSD

[Eric Christopher]

On Thu, May 8, 2014 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On May 8, 2014, at 2:50 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>> Basically the only way this would be a problem is if FreeBSD doesn't
>> ship debug info for part of the libraries (which is, I believe, the
>> problem that Adrian ran into on OSX and dtrace/kernel modules). The
>> lldb "problem" is just a bug there. I.e. if you have clang build all
>> of the debug info for all of your binaries then it should work just
>> fine.
>>
>> Adrian: Did I miss anything on the problems you were seeing?
>
> As far as I can tell (and Greg’s first reply in the lldb-dev thread seems to agree with this), your summary is accurate. LLDB should not crash if there is complete debug information available. It will perform very badly because it will have to search the DWARF for every compile unit for the complete definition, but as far as I understand it, it is not supposed the crash (as long as the definition for that class actually is somewhere). Other consumers like ctfconvert (aka dtrace), however, cannot deal with this at all, which is the other reason why we decided to disable this by default on Darwin.
>

I'm still surprised about ctfconvert. I mean, there are some pretty
basic c++ things that you can't do otherwise.

That said, was it the lack of some information for kernel modules that
caused it or was it the DW_AT_declaration bit? If it's the latter then
the version of ctfconvert on freebsd might be able to cope with it
since gcc has been emitting this kind of debug information for "some
time now".

Ed?

-eric

> -- adrian
>
>>
>> -eric
>>
>> On Thu, May 8, 2014 at 2:48 PM, Ed Maste <emaste at freebsd.org> wrote:
>>> On 8 May 2014 17:29, David Blaikie <dblaikie at gmail.com> wrote:
>>>>
>>>> Ugh. Didn't realize LLDB still had that assert text there. That's
>>>> grossly misleading.
>>>
>>> Note though that I didn't encounter LLDB's "suggestion" in the path I
>>> took to the clang assertion.  Perhaps it's a difference between
>>> forward declarations (as in the mailing list thread) vs. the "debug
>>> info only where the vtable is" optimization that I presumably
>>> encountered.
>