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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
