- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using lldb-test symbols will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always Int, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type long is of same width as int in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type long double and double have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
zturner lldb-commits davide asmith
- rLLDB322995: [SymbolFilePDB] Fix null array access when parsing the type of a function…
rL322995: [SymbolFilePDB] Fix null array access when parsing the type of a function…
rG563799b3a6cf: [SymbolFilePDB] Fix null array access when parsing the type of a function…
This fix is part of a larger set of changes to retrieve the type for a function signature and I don't see how to test for this without those changes. With all the other changes, lldb-test fails without this fix and passes with it. So it's implicitly already tested.
This was originally written as a unit test because at the time we didn't have lldb-test. To be honest I think it's time to remove these checked in binaries and convert everything to FileCheck tests. There's a couple of reasons this is more practical. For starters, the binaries can be really large and having lots of large binaries in the repo is a real drag for developers. Secondly, we've recently had some bug reports where some virus scan software is flagging our executables as malicious due to some heuristics. So while you're just modifying an existing binary / test, if it's not a ton of work I would really prefer standardizing on lldb-test + FileCheck for this sort of thing. Did you explore that at all?
While there's a little higher up front cost because you have to go update the lldb-test tool to support this, after that work is done it will make writing future tests very easy. All you would need is something like this:
REQUIRES: system-windows RUN: clang-cl /Z7 /c %S/Inputs/foo.cpp /o %T/foo.cpp.obj RUN: link /DEBUG /PDB:%T/foo.cpp.pdb /Fo:%T/foo.cpp.exe RUN: lldb-test symbols -types foo.cpp.exe | FileCheck %s CHECK: int(*FuncPointerTypedef)(); CHECK: int(*VariadicFuncPointerTypedef)(char,...);
I have reverted this because this breaks the lldb-Unit::SymbolFilePDBTests.TestTypedefs test http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715. My guess is that this is because you did not update the checked-in exe to account for the changes in it's source. I'll leave up to you and Zachary to figure out whether you actually want to update the exe or test everything using the lldb-test approach, but in the mean time, we cannot have failing tests in the repository.