On Thu, May 8, 2014 at 4:05 PM, Adrian Prantl <[email protected]> wrote: > > On May 8, 2014, at 3:46 PM, Eric Christopher <[email protected]> wrote: > > On Thu, May 8, 2014 at 3:36 PM, Adrian Prantl <[email protected]> wrote: > > > On May 8, 2014, at 2:50 PM, Eric Christopher <[email protected]> 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 <[email protected]> wrote: > > On 8 May 2014 17:29, David Blaikie <[email protected]> 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. > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
