Awesome, thanks for the quick and detailed response! On Thu, Jun 28, 2012 at 5:12 PM, Greg Clayton <[email protected]> wrote:
> > 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 > > -- -- Talin
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
