[llvm-dev] [lldb-dev] Adding DWARF5 accelerator table support to llvm

[David Blaikie via llvm-dev]

On Mon, Jun 18, 2018 at 9:54 AM <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 more
> > 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.
>

A couple of questionable reasons:

1) name/overload resolution - having the names of functions you can't call
(because they've been inlined away, never instantiated, etc) means that if
a debugger is evaluating an expression it won't accidentally resolve a call
to a different function from the one that would've been used in the source
language. (eg: a class with foo(int) and foo(T) - if you call foo(true) -
but the debugger doesn't know any foo(T) exists, so it calls foo(int),
which could be varying degrees of unfortunate)

This could happen for any function though, and it'd certainly be
impractical to include all function declarations (especially for
non-members), all types, etc, to ensure that all names are available to
validate any ambiguities, etc.

2) Possible that there are libraries linked in that themselves don't have
debug info - but include specializations of a template (or definitions of
any declared function, really) - so having the debug info could be used to
know about those functions (given at least Itanium mangling, though - I'm
not sure the debug info would be necessary, maybe looking at the mangled
name would be sufficient for a debugger to know "oh, this function is a
member of this class and has these parameter types" - hmm, guess it
wouldn't know the return type without debug info, perhaps)


>
> Feel free to start a new thread if this is straying too far from the
> discussion that already strayed from the original topic. :-)
> Thanks,
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180618/2a825799/attachment-0001.html>