llvm-project/lldb/lit/SymbolFile/PDB/enums-layout.test

46 lines
1.8 KiB
Plaintext
Raw Normal View History

[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-24 04:35:19 +08:00
REQUIRES: windows
RUN: clang-cl -m32 /Z7 /c /GS- %S/Inputs/SimpleTypesTest.cpp /o %T/SimpleTypesTest.cpp.enums.obj
RUN: link %T/SimpleTypesTest.cpp.enums.obj /DEBUG /nodefaultlib /ENTRY:main /OUT:%T/SimpleTypesTest.cpp.enums.exe
RUN: lldb-test symbols %T/SimpleTypesTest.cpp.enums.exe | FileCheck %s
; FIXME: PDB does not have information about scoped enumeration (Enum class) so the
; compiler type used is the same as the one for unscoped enumeration.
CHECK: Module [[CU:.*]]
CHECK-DAG: {{^[0-9A-F]+}}: SymbolVendor ([[CU]])
CHECK: Type{{.*}} , name = "Enum", size = 4, decl = SimpleTypesTest.cpp:19, compiler_type = {{.*}} enum Enum {
[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-24 04:35:19 +08:00
CHECK-NEXT: RED,
CHECK-NEXT: GREEN,
CHECK-NEXT: BLUE
CHECK-NEXT:}
CHECK: Type{{.*}} , name = "EnumConst", size = 4, decl = SimpleTypesTest.cpp:22, compiler_type = {{.*}} enum EnumConst {
[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-24 04:35:19 +08:00
CHECK-NEXT: LOW,
CHECK-NEXT: NORMAL,
CHECK-NEXT: HIGH
CHECK-NEXT:}
CHECK: Type{{.*}} , name = "EnumEmpty", size = 4, decl = SimpleTypesTest.cpp:25, compiler_type = {{.*}} enum EnumEmpty {
[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-24 04:35:19 +08:00
CHECK-NEXT:}
CHECK: Type{{.*}} , name = "EnumUChar", size = 1, decl = SimpleTypesTest.cpp:28, compiler_type = {{.*}} enum EnumUChar {
[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-24 04:35:19 +08:00
CHECK-NEXT: ON,
CHECK-NEXT: OFF,
CHECK-NEXT: AUTO
CHECK-NEXT:}
; Note that `enum EnumClass` is tested instead of `enum class EnumClass`
CHECK: Type{{.*}} , name = "EnumClass", size = 4, decl = SimpleTypesTest.cpp:32, compiler_type = {{.*}} enum EnumClass {
[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-24 04:35:19 +08:00
CHECK-NEXT: YES,
CHECK-NEXT: NO,
CHECK-NEXT: DEFAULT
CHECK-NEXT:}
CHECK: Type{{.*}} , name = "EnumStruct", size = 4, decl = SimpleTypesTest.cpp:35, compiler_type = {{.*}} enum EnumStruct {
[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-24 04:35:19 +08:00
CHECK-NEXT: red,
CHECK-NEXT: blue,
CHECK-NEXT: black
CHECK-NEXT:}
CHECK-DAG: {{^[0-9A-F]+}}: CompileUnit{{[{]0x[0-9a-f]+[}]}}, language = "c++", file = '{{.*}}\SimpleTypesTest.cpp'