[Lldb-commits] [PATCH] D69309: Support template instantiation in the expression evaluator

Thu Nov 21 01:28:40 PST 2019

labath added a comment.

In D69309#1754593 <https://reviews.llvm.org/D69309#1754593>, @jarin wrote:

> In D69309#1752738 <https://reviews.llvm.org/D69309#1752738>, @friss wrote:
>
> > Sorry that I haven't reviewed the patch, but there's something I'd like to point out before anyone invests a lot of time into plugin holes in our current template support code.
> >
> > It would be great to fix the way templates are represented, because currently the debug info doesn't allow us to answer Clang's requests correctly. There is the beginning of a discussion here: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180507/040689.html
> >
> > Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.
>
>
> Having an entity for the template itself would be great. However, that would require compiler changes, so only the code compiled with new compilers would benefit, no? I am afraid we need a story for older toolchains, too.

Well, I think that's a question of tradeoffs -- i.e., how many hoops you would need to jump through to support the old compiler. Since the "manual" index needs to scan the debug info anyway, I think that the cost of supporting this flow (both in terms of runtime and code complexity) would be sufficiently low to enable that. However, for the apple/dwarf5 indexes the cost (both kinds) might be prohibitively high...

I don't think that supporting this only in the "manual" case would be that bad, but would still probably want to consider the problem as a whole, and come up with an accelerator story too, so that they can eventually catch up in terms of functionality...

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69309/new/

https://reviews.llvm.org/D69309