maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/llvm-pdbdump/simple-padding-graphical.test

126 lines
5.6 KiB
Plaintext
Raw Normal View History

Rename llvm-pdbdump -> llvm-pdbutil. This is to reflect the evolving nature of the tool as being useful for more than just dumping PDBs, as it can do many other things. Differential Revision: https://reviews.llvm.org/D34062 llvm-svn: 305106
2017-06-10 04:46:17 +08:00
; RUN: llvm-pdbutil pretty -classes -class-definitions=layout \
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; RUN: -include-types=SimplePad %p/Inputs/SimplePaddingTest.pdb > %t
; RUN: FileCheck -input-file=%t %s -check-prefix=NO_PADDING
; RUN: FileCheck -input-file=%t %s -check-prefix=UNION
; RUN: FileCheck -input-file=%t %s -check-prefix=NESTED_UNION
; RUN: FileCheck -input-file=%t %s -check-prefix=PAD_FROM_FIELDS1
; RUN: FileCheck -input-file=%t %s -check-prefix=PAD_FROM_FIELDS2
; RUN: FileCheck -input-file=%t %s -check-prefix=NO_PAD_IN_BASE
; RUN: FileCheck -input-file=%t %s -check-prefix=PAD_IN_DERIVED
; RUN: FileCheck -input-file=%t %s -check-prefix=EMPTY_BASE
; RUN: FileCheck -input-file=%t %s -check-prefix=VFPTR
; RUN: FileCheck -input-file=%t %s -check-prefix=MULTIPLE_INHERIT
; RUN: FileCheck -input-file=%t %s -check-prefix=MULTIPLE_INHERIT2
; RUN: FileCheck -input-file=%t %s -check-prefix=DEEP_INHERIT
; RUN: FileCheck -input-file=%t %s -check-prefix=AGGREGATE
; NO_PADDING: struct SimplePadNoPadding [sizeof = 8] {
; NO_PADDING-NEXT: data +0x00 [sizeof=4] int X
; NO_PADDING-NEXT: data +0x04 [sizeof=4] int Y
; NO_PADDING-NEXT: }
; UNION: struct SimplePadUnion [sizeof = 16] {
; UNION-NEXT: data +0x00 [sizeof=4] int X
; UNION-NEXT: data +0x00 [sizeof=8] __int64 Y
; UNION-NEXT: data +0x00 [sizeof=16] SimplePadUnion::
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; UNION-NEXT: data +0x00 [sizeof=4] int X
; UNION-NEXT: <padding> (4 bytes)
; UNION-NEXT: data +0x08 [sizeof=8] __int64 Y
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; UNION-NEXT: }
; NESTED_UNION: struct {{SimplePadUnion::.*}} [sizeof = 16] {
; NESTED_UNION-NEXT: data +0x00 [sizeof=4] int X
; NESTED_UNION-NEXT: <padding> (4 bytes)
; NESTED_UNION-NEXT: data +0x08 [sizeof=8] __int64 Y
; NESTED_UNION-NEXT: }
; PAD_FROM_FIELDS1: struct SimplePadFields1 [sizeof = 4] {
; PAD_FROM_FIELDS1-NEXT: data +0x00 [sizeof=1] char A
; PAD_FROM_FIELDS1-NEXT: data +0x01 [sizeof=1] char B
; PAD_FROM_FIELDS1-NEXT: data +0x02 [sizeof=1] char C
; PAD_FROM_FIELDS1-NEXT: <padding> (1 bytes)
; PAD_FROM_FIELDS1-NEXT: }
; PAD_FROM_FIELDS2: struct SimplePadFields2 [sizeof = 8] {
; PAD_FROM_FIELDS2-NEXT: data +0x00 [sizeof=4] int Y
; PAD_FROM_FIELDS2-NEXT: data +0x04 [sizeof=1] char X
; PAD_FROM_FIELDS2-NEXT: <padding> (3 bytes)
; PAD_FROM_FIELDS2-NEXT: }
; NO_PAD_IN_BASE: struct SimplePadBase [sizeof = 4] {
; NO_PAD_IN_BASE-NEXT: data +0x00 [sizeof=4] int X
; NO_PAD_IN_BASE-NEXT: }
; PAD_IN_DERIVED: struct SimplePadDerived [sizeof = 16]
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; PAD_IN_DERIVED-NEXT: : public SimplePadBase {
; PAD_IN_DERIVED-NEXT: base +0x00 [sizeof=4] SimplePadBase
; PAD_IN_DERIVED-NEXT: data +0x00 [sizeof=4] int X
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; PAD_IN_DERIVED-NEXT: <padding> (4 bytes)
; PAD_IN_DERIVED-NEXT: data +0x08 [sizeof=8] __int64 Y
; PAD_IN_DERIVED-NEXT: }
; EMPTY_BASE: struct SimplePadEmpty [sizeof = 8]
; EMPTY_BASE-NEXT: : public SimplePadEmptyBase1
; EMPTY_BASE-NEXT: , public SimplePadEmptyBase2 {
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; EMPTY_BASE-NEXT: base +0x00 [sizeof=1] SimplePadEmptyBase1
; EMPTY_BASE-NEXT: base +0x01 [sizeof=1] SimplePadEmptyBase2
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; EMPTY_BASE-NEXT: <padding> (2 bytes)
; EMPTY_BASE-NEXT: data +0x04 [sizeof=4] int X
; EMPTY_BASE-NEXT: }
; VFPTR: struct SimplePadVfptr [sizeof = 8] {
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; VFPTR-NEXT: vfptr +0x00 [sizeof=4]
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; VFPTR-NEXT: data +0x04 [sizeof=4] int X
; VFPTR-NEXT: }
; MULTIPLE_INHERIT: struct SimplePadMultiInherit [sizeof = 8]
; MULTIPLE_INHERIT-NEXT: : public NonEmptyBase1
; MULTIPLE_INHERIT-NEXT: , public NonEmptyBase2 {
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; MULTIPLE_INHERIT-NEXT: base +0x00 [sizeof=1] NonEmptyBase1
; MULTIPLE_INHERIT-NEXT: data +0x00 [sizeof=1] bool X
; MULTIPLE_INHERIT-NEXT: base +0x01 [sizeof=1] NonEmptyBase2
; MULTIPLE_INHERIT-NEXT: data +0x01 [sizeof=1] bool Y
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; MULTIPLE_INHERIT-NEXT: <padding> (2 bytes)
; MULTIPLE_INHERIT-NEXT: data +0x04 [sizeof=4] int X
; MULTIPLE_INHERIT-NEXT: }
; MULTIPLE_INHERIT2: SimplePadMultiInherit2 [sizeof = 16]
; MULTIPLE_INHERIT2-NEXT: : public SimplePadFields1
; MULTIPLE_INHERIT2-NEXT: , public SimplePadFields2 {
[llvm-pdbdump] Re-write the record layout code to be more resilient. This reworks the way virtual bases are handled, and also the way padding is detected across multiple levels of aggregates, producing a much more accurate result. llvm-svn: 301203
2017-04-25 01:47:24 +08:00
; MULTIPLE_INHERIT2-NEXT: base +0x00 [sizeof=3] SimplePadFields1
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; MULTIPLE_INHERIT2-NEXT: data +0x00 [sizeof=1] char A
; MULTIPLE_INHERIT2-NEXT: data +0x01 [sizeof=1] char B
; MULTIPLE_INHERIT2-NEXT: data +0x02 [sizeof=1] char C
[llvm-pdbdump] Re-write the record layout code to be more resilient. This reworks the way virtual bases are handled, and also the way padding is detected across multiple levels of aggregates, producing a much more accurate result. llvm-svn: 301203
2017-04-25 01:47:24 +08:00
; MULTIPLE_INHERIT2-NEXT: <padding> (1 bytes)
; MULTIPLE_INHERIT2-NEXT: base +0x04 [sizeof=5] SimplePadFields2
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; MULTIPLE_INHERIT2-NEXT: data +0x04 [sizeof=4] int Y
; MULTIPLE_INHERIT2-NEXT: data +0x08 [sizeof=1] char X
[llvm-pdbdump] Re-write the record layout code to be more resilient. This reworks the way virtual bases are handled, and also the way padding is detected across multiple levels of aggregates, producing a much more accurate result. llvm-svn: 301203
2017-04-25 01:47:24 +08:00
; MULTIPLE_INHERIT2-NEXT: <padding> (3 bytes)
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; MULTIPLE_INHERIT2-NEXT: data +0x0c [sizeof=4] int X
; MULTIPLE_INHERIT2-NEXT: }
; DEEP_INHERIT: struct SimplePadTwoLevelInherit [sizeof = 16]
; DEEP_INHERIT-NEXT: : public OneLevelInherit {
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; DEEP_INHERIT-NEXT: base +0x00 [sizeof=4] OneLevelInherit
; DEEP_INHERIT-NEXT: base +0x00 [sizeof=1] NonEmptyBase1
; DEEP_INHERIT-NEXT: data +0x00 [sizeof=1] bool X
; DEEP_INHERIT-NEXT: <padding> (1 bytes)
; DEEP_INHERIT-NEXT: data +0x02 [sizeof=2] short Y
; DEEP_INHERIT-NEXT: <padding> (4 bytes)
; DEEP_INHERIT-NEXT: data +0x08 [sizeof=8] __int64 Z
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; DEEP_INHERIT-NEXT: }
[llvm-pdbdump] Merge functionality of graphical and text dumpers. The *real* difference between these two was that a) The "graphical" dumper could recurse, while the text one could not. b) The "text" dumper could display nested types and functions, while the graphical one could not. Merge these two so that there is only one dumper that can recurse arbitrarily deep and optionally display nested types or not. llvm-svn: 301204
2017-04-25 01:47:52 +08:00
; AGGREGATE: struct SimplePadAggregate [sizeof = 12] {
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; AGGREGATE-NEXT: data +0x00 [sizeof=1] NonEmptyBase1 X
[llvm-pdbdump] Recursively dump class layout. llvm-svn: 300258
2017-04-14 05:11:00 +08:00
; AGGREGATE-NEXT: data +0x00 [sizeof=1] bool X
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; AGGREGATE-NEXT: <padding> (3 bytes)
; AGGREGATE-NEXT: data +0x04 [sizeof=4] int Y
[llvm-pdbdump] Merge functionality of graphical and text dumpers. The *real* difference between these two was that a) The "graphical" dumper could recurse, while the text one could not. b) The "text" dumper could display nested types and functions, while the graphical one could not. Merge these two so that there is only one dumper that can recurse arbitrarily deep and optionally display nested types or not. llvm-svn: 301204
2017-04-25 01:47:52 +08:00
; AGGREGATE-NEXT: data +0x08 [sizeof=4] SimplePadFields1 Fields
; AGGREGATE-NEXT: data +0x08 [sizeof=1] char A
; AGGREGATE-NEXT: data +0x09 [sizeof=1] char B
; AGGREGATE-NEXT: data +0x0a [sizeof=1] char C
; AGGREGATE-NEXT: <padding> (1 bytes)
[llvm-pdbdump] More advanced class definition dumping. Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
2017-04-13 07:18:21 +08:00
; AGGREGATE-NEXT: }