Commit Graph

4 Commits

Author SHA1 Message Date
Aaron Smith 7abdf2d24f [SymbolFilePDB] Get line number for PDBSymbolTypeEnum
Reviewers: zturner, lldb-commits, rnk

Reviewed By: zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D44164

llvm-svn: 326858
2018-03-07 00:35:27 +00:00
Aaron Smith ec40f818c6 [SymbolFilePDB] Fix null array access when parsing the type of a function without any arguments, i.e. 'int main()' and add support to test it
Summary:
- 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 information 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.

Reviewers: zturner, lldb-commits

Reviewed By: zturner

Subscribers: majnemer, llvm-commits

Differential Revision: https://reviews.llvm.org/D42434

llvm-svn: 323255
2018-01-23 20:35:19 +00:00
Pavel Labath 11d0b29446 Revert "[SymbolFilePDB] Fix null array access when parsing the type of a function without any arguments, i.e. 'int main()' and add support to test it"
This reverts commit r322995, as it breaks
lldb-Unit::SymbolFilePDBTests.TestTypedefs
<http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715>.

llvm-svn: 323102
2018-01-22 11:51:56 +00:00
Aaron Smith 563799b3a6 [SymbolFilePDB] Fix null array access when parsing the type of a function without any arguments, i.e. 'int main()' and add support to test it
Summary:
- 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.

Reviewers: zturner, lldb-commits, davide, asmith

Reviewed By: zturner, asmith

Subscribers: llvm-commits, davide

Differential Revision: https://reviews.llvm.org/D41427

llvm-svn: 322995
2018-01-19 21:55:44 +00:00