[Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

> This info is contained in the Symbols stream, not in the TPI stream. As far as I understand, we can't find in a simple way the link between a LF_ONEMETHOD record and a corresponding S_GPROC32 record. I think it's the place, where we need to use the approach similar to D54053 <https://reviews.llvm.org/D54053> (to parse mangled names and to build some part of AST based on this info). That's what I'm planning to implement next. Do you have any objections on this? Or may be there's a better way to solve this?

I think it's probably best to skip this part for now and come back to it later.  The only thing that will be missing is the ability to use member function templates in expressions.  Of course we need this eventually, but probably there is more useful stuff to work on first.

One idea for implementing this though might be to add a pre-processing step of the publics stream similar to how we pre-process the TPI stream.  This would also allow us to find mangled names of global functions as well (currently even for global functions, we create an empty `Mangled` structure when LLDB asks us for the mangled name).  One pass over the publics stream should be simpler and more straightforward than a pass over every single module's symbol stream.  From there we have the address, which tells us the module, and then we can use the `CompilandIndexItem::FindSymbolsByVa()` to find the `S_GPROC32` record, and from there find the type.  But I think this is a large effort for low value, so we should maybe wait until the easier stuff is done first.  I haven't looked at the rest of the patch yet, but I will in a little bit.  Thanks!


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D56126