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