[Lldb-commits] [PATCH] D113930: [LLDB][NativePDB] Fix function decl creation for class methods

Zequan Wu via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Dec 6 16:18:11 PST 2021


zequanwu added a comment.

In D113930#3174406 <https://reviews.llvm.org/D113930#3174406>, @labath wrote:

> I still think that the piecemeal addition of member functions is a problem. While I don't think that changing the parsing order in `Module::ParseAllDebugSymbols` would be a problem (that function is only called from lldb-test), I think that would only hide the problem. Looking at what happens in the DWARF case, I /think/ (the code is fairly messy, so I could be wrong) that we don't create a clang ast representation for the function in `ParseFunctions`. We only create an lldb_private::Function (in `DWARFASTParserClang::ParseFunctionFromDWARF`). The ast entity only gets created in `SymbolFileDWARF::ParseTypes` (->ParseType->DWARFASTParserClang->ParseTypeFromDWARF). This kinda makes sense since we only need the ast representation of the method when we start dealing its class.

>From what I tested on dwarf plugin, `lldb-test symbols -dump-ast ` doesn't print any ast decl, except a skeleton class decl. After adding some logs at (https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L1026), it doesn't get executed.

  $ lldb-test symbols -dump-ast ast-methods.exe
  Module: ast-methods.exe
  struct Struct;

Nevertheless I think it works in dwarf because it creates the decls if die is `DW_TAG_subprogram`/`DW_TAG_inlined_subroutine `/`DW_TAG_subroutine_type ` (https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L522). We can associate a decl with a die. But we can't associate a type record with a decl when parsing type stream in PDB.

> So I have a feeling that the real solution here is to avoid creating an ast entry for the function in the first phase. Then you should be able to create the full class declaration in the second phase, as you will have complete information there.

If we don't create ast entries at `ParseFunctions`, non-class-member functions will not have ast decls. If we just create ast decls for non-class-member functions in `ParseFunctions`, we are expecting that `ParseTypes` is always called after `ParseFunctions` to complete the decl creation for member functions, which is not right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113930



More information about the lldb-commits mailing list