[lldb-dev] Supporting custom debug formats

[Talin]

Awesome, thanks for the quick and detailed response!

On Thu, Jun 28, 2012 at 5:12 PM, Greg Clayton <gclayton at apple.com> 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
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120628/43fca4ac/attachment.html>