[PATCH] Enable standalone-debug by default on FreeBSD

[Eric Christopher]

On Thu, May 8, 2014 at 4:05 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On May 8, 2014, at 3:46 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> 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".
>
>
> I can’t really answer for ctfconvert. For LLDB, we had a situation where
> kernel extensions are supposed to inherit from classes defined in, e.g.,
> IOKit. Since the base class’ vtable lives in outside of the extension, the
> debug info for the base class would be elided. In situations where the debug
> info for the kernel is unavailable, LLDB then wouldn't be able to do the
> memory layout of the type of the class defined in the extension any more.
>

Ayup. I thought that was the case with ctfconvert as well since (IIRC)
it likes to go grubbing around in kernel memory too.

-eric

> -- adrian
>
> 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.
>
>