[lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm
Eric Christopher via lldb-dev
lldb-dev at lists.llvm.org
Mon Jun 18 10:03:36 PDT 2018
On Mon, Jun 18, 2018 at 9:57 AM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> > On Jun 18, 2018, at 9:54 AM, <paul.robinson at sony.com> <
> paul.robinson at sony.com> wrote:
> >> Greg wrote:
> >>> Pavel wrote:
> >>> That said, having DWARF be able to represent the template member
> >>> functions in an abstract way also sounds like nice thing to have from
> >>> a debug info format.
> >> Yes, that would be great, but will require DWARF changes and is much
> >> long term.
> > I'm curious what utility this has, other than tidying up the Clang AST
> > interface part (because you know what templates exist inside the class).
> > I mean, you can't instantiate new functions; and if you're trying to
> > call an existing instance, you have to go find it anyway, in whichever
> > CU it happens to have been instantiated.
> > Feel free to start a new thread if this is straying too far from the
> > discussion that already strayed from the original topic. :-)
> I do agree. Probably no one else will want/need this in DWARF except us as
> I don't believe anyone else is re-creating compiler types with DWARF. Not
> that I don't think it is a good idea for debuggers to do as it allows the
> compiler to be used in the debugger. That being said, we should probably
> look for solutions that are better for all DWARF clients or just fix things
> in our debugger.
Oh, I've seen DWARF used outside of lldb's context to reconstruct types - I
also think it's a fairly legitimate use of debug info. If we can make it
easier to reconstruct the actual program...
> > Thanks,
> > --paulr
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev