On Jun 28, 2012, at 12:23 PM, Talin wrote: > I'd be curious to know how difficult it would be to support a > language-specific debugging format in lldb. Let's say I have a language that > supports reflection, which means that the executable file contains a complete > description of all data types and functions. Rather than write this > information out twice (once as reflection metadata, and once as DWARD DIEs), > I'd like to make it so that the debugger can interpret the reflection data > directly, avoiding the need to use DWARF at all.
This wouldn't be too hard. You would need to subclass lldb_private::SymbolFile and implement the items in the API. The hardest part is converting the types in the debug info into Clang types, but we abstracted this into classes that aren't part of the DWARF parser, so that shouldn't be too hard. We also parse class/struct/unions types as forward declaration types first, and have the DWARF parser implement an AST external source so the classes can complete themselves lazily as needed. > > I'd also like to support the idea of "source libraries", similar to Java's > concept of "source jars", in other words, packed archives of source files > that are reachable via the library search path, which can be shipped along > with a binary for a library and allow convenient access to the source code > for debugging. This depends on where the bits for the "source libraries" would live. Would they be a stand alone file that is referenced from the debug info? If so we can make a lldb_private::SourceBundle class that could be subclassed for different source jar implementations. Then the "SymbolFile" classes can have a functions added to them like: SourceBundleSP SymbolFile::GetSourceBundle(); If the symbol file knows about a source bundle, it can return a new non-NULL shared pointer, or an empty SourceBundleSP if the symbol file does not have a reference to one. This can alternately be put into the lldb_private::ObjectFile class if the source bundle reference is in the object file. Then this can be exposed via the lldb_private::Module that owns both the lldb_private::ObjectFile and lldb_private::SymbolVendor (which owns the lldb_private::SymbolFile). > > How difficult would it be to extend lldb to do this? This wouldn't be too hard. The lldb_private::SourceManager can then be modified to look for the file in a Module's SourceBundle when looking for sources. > > -- > -- Talin > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
