Removed GetParentDeclContextForSymbol as this is not necesssary. We can get
the demangled names from CVSymbol and then using it to create tag decl or
namespace decl. This also fixed a bug when icf applied.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp | ||
---|---|---|
631 | What if the two symbols have the same address (same code) and the same base name (but are e.g. in different namespaces)? | |
634–661 | I know you didn't write this, but I still have to express my surprise at the existence of this code. My don't have anything like that -- using demangled names to look up things -- in the DWARF plugin. There, you can find the containing context by just going "up" in the DIE tree. I don't know if that is possible in PDB, but the current implementation seems fairly fragile, and I suspect it could be broken if the user overrides a mangled name of a symbol (void f() asm("my_linkage_name");). |
lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp | ||
---|---|---|
634–661 | For namespace, I don't see any symbol record for it. All members of namespace, functions or variables, just have namespace string as a prefix for their names, like N1::N2::func. |
- Removed GetParentDeclContextForSymbol as this is not necesssary. We can get the demangled names from CVSymbol and then using it to create tag decl or namespace decl.
- Add test cases with same base names, but with different namespace/class.
Well, I still don't claim to understand this code, but I am happy to stamp anything that fixes bugs by deleting code.
Just as an idea for future work, you may want to check that we're correctly handling functions with unusual linkage names (e.g. due to asm labels). In DWARF, we're adding explicit asm labels with the debug-info-provided linkage names to make this work.
What if the two symbols have the same address (same code) and the same base name (but are e.g. in different namespaces)?