maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Object/stackmap-dump.test

174 lines
7.3 KiB
Plaintext
Raw Normal View History

[llvm-readobj] Change -long-option to --long-option in tests. NFC We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
2019-05-01 13:27:20 +08:00
RUN: llvm-readobj --stackmap %p/Inputs/stackmap-test.macho-x86-64 | FileCheck %s
[StackMaps] Add a lightweight parser for stackmap version 1 sections. The parser provides a convenient interface for reading llvm stackmap v1 sections in object files. This patch also includes a new option for llvm-readobj, '-stackmap', which uses the parser to pretty-print stackmap sections for debugging/testing purposes. llvm-svn: 240860
2015-06-27 07:56:53 +08:00
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
; Note: the macho object file in this test was generated in the following way:
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
; llc -mtriple=x86_64-apple-darwin test/CodeGen/X86/stackmap.ll -o test/Object/Inputs/stackmap-test.macho-x86-64 -filetype=obj
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: LLVM StackMap Version: 3
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: Num Functions: 16
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 24, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: Function address: 0, stack size: 56, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 56, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 56, callsite record count: 2
CHECK-NEXT: Function address: 0, stack size: 8, callsite record count: 4
CHECK-NEXT: Function address: 0, stack size: 56, callsite record count: 1
CHECK-NEXT: Function address: 0, stack size: 18446744073709551615, callsite record count: 1
CHECK-NEXT: Num Constants: 3
CHECK-NEXT: #1: 2147483648
CHECK-NEXT: #2: 4294967295
CHECK-NEXT: #3: 4294967296
CHECK-NEXT: Num Records: 20
CHECK-NEXT: Record ID: 1, instruction offset: 4
CHECK-NEXT: 12 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Constant 4294967295, size: 8
CHECK-NEXT: #2: Constant 4294967295, size: 8
CHECK-NEXT: #3: Constant 65536, size: 8
CHECK-NEXT: #4: Constant 2000000000, size: 8
CHECK-NEXT: #5: Constant 2147483647, size: 8
CHECK-NEXT: #6: Constant 4294967295, size: 8
CHECK-NEXT: #7: Constant 4294967295, size: 8
CHECK-NEXT: #8: Constant 0, size: 8
CHECK-NEXT: #9: ConstantIndex #0 (2147483648), size: 8
CHECK-NEXT: #10: ConstantIndex #1 (4294967295), size: 8
CHECK-NEXT: #11: ConstantIndex #2 (4294967296), size: 8
CHECK-NEXT: #12: Constant 4294967295, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
CHECK: Record ID: 3, instruction offset: 22
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#3, size: 8
CHECK-NEXT: #2: Register R#14, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 4, instruction offset: 10
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#5, size: 8
CHECK-NEXT: #2: Register R#4, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 5, instruction offset: 4
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#0, size: 8
CHECK-NEXT: #2: Register R#5, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 2 live-outs: [ R#0 (8-bytes) R#7 (8-bytes) ]
CHECK: Record ID: 6, instruction offset: 4
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#4, size: 8
CHECK-NEXT: #2: Register R#2, size: 8
[StackMaps] Add a lightweight parser for stackmap version 1 sections. The parser provides a convenient interface for reading llvm stackmap v1 sections in object files. This patch also includes a new option for llvm-readobj, '-stackmap', which uses the parser to pretty-print stackmap sections for debugging/testing purposes. llvm-svn: 240860
2015-06-27 07:56:53 +08:00
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK: Record ID: 7, instruction offset: 10
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#2, size: 8
CHECK-NEXT: #2: Register R#8, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
CHECK: Record ID: 8, instruction offset: 10
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#2, size: 8
CHECK-NEXT: #2: Register R#8, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 2 live-outs: [ R#0 (8-bytes) R#7 (8-bytes) ]
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: Record ID: 11, instruction offset: 4
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 17 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#9, size: 8
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK-NEXT: #2: Indirect [R#6 + 16], size: 8
CHECK-NEXT: #3: Indirect [R#6 + 24], size: 8
CHECK-NEXT: #4: Indirect [R#6 + 32], size: 8
CHECK-NEXT: #5: Indirect [R#6 + 40], size: 8
CHECK-NEXT: #6: Indirect [R#6 + 48], size: 8
CHECK-NEXT: #7: Indirect [R#6 + 56], size: 8
CHECK-NEXT: #8: Indirect [R#6 + 64], size: 8
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #9: Indirect [R#6 + 72], size: 8
CHECK-NEXT: #10: Indirect [R#6 + 80], size: 8
CHECK-NEXT: #11: Indirect [R#6 + 88], size: 8
CHECK-NEXT: #12: Indirect [R#6 + 96], size: 8
CHECK-NEXT: #13: Indirect [R#6 + 104], size: 8
CHECK-NEXT: #14: Indirect [R#6 + 112], size: 8
CHECK-NEXT: #15: Indirect [R#6 + 120], size: 8
CHECK-NEXT: #16: Indirect [R#6 + 128], size: 8
CHECK-NEXT: #17: Indirect [R#6 + 136], size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: Record ID: 12, instruction offset: 4
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 17 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#0, size: 8
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK-NEXT: #2: Indirect [R#6 + 16], size: 8
CHECK-NEXT: #3: Indirect [R#6 + 24], size: 8
CHECK-NEXT: #4: Indirect [R#6 + 32], size: 8
CHECK-NEXT: #5: Indirect [R#6 + 40], size: 8
CHECK-NEXT: #6: Indirect [R#6 + 48], size: 8
CHECK-NEXT: #7: Indirect [R#6 + 56], size: 8
CHECK-NEXT: #8: Indirect [R#6 + 64], size: 8
CHECK-NEXT: #9: Indirect [R#6 + 72], size: 8
CHECK-NEXT: #10: Indirect [R#6 + 80], size: 8
CHECK-NEXT: #11: Indirect [R#6 + 88], size: 8
CHECK-NEXT: #12: Indirect [R#6 + 96], size: 8
CHECK-NEXT: #13: Indirect [R#6 + 104], size: 8
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #14: Indirect [R#6 + 112], size: 8
CHECK-NEXT: #15: Indirect [R#6 + 120], size: 8
CHECK-NEXT: #16: Indirect [R#6 + 128], size: 8
CHECK-NEXT: #17: Indirect [R#6 + 136], size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 13, instruction offset: 50
CHECK-NEXT: 1 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Indirect [R#6 + -48], size: 4
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 14, instruction offset: 24
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Register R#0, size: 1
CHECK-NEXT: #2: Register R#3, size: 1
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 15, instruction offset: 4
CHECK-NEXT: 1 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Constant 33, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: Record ID: 16, instruction offset: 16
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 1 locations:
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK-NEXT: #1: Direct R#6 + -40, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: Record ID: 17, instruction offset: 16
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 2 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Direct R#6 + -8, size: 8
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK-NEXT: #2: Direct R#6 + -16, size: 8
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
CHECK: Record ID: 4294967295, instruction offset: 4
CHECK-NEXT: 0 locations:
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 4294967296, instruction offset: 4
CHECK-NEXT: 0 locations:
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 9223372036854775807, instruction offset: 4
CHECK-NEXT: 0 locations:
CHECK-NEXT: 0 live-outs: [ ]
CHECK: Record ID: 18446744073709551615, instruction offset: 4
CHECK-NEXT: 0 locations:
CHECK-NEXT: 1 live-outs: [ R#7 (8-bytes) ]
CHECK: Record ID: 16, instruction offset: 18
CHECK-NEXT: 1 locations:
[StackMaps] Add location size to llvm-readobj -stackmap output The size field of a location can be different for each entry, so it is useful to have this displayed in the output of llvm-readobj -stackmap. Below is an example of how the output would look: Record ID: 2882400000, instruction offset: 16 3 locations: #1: Constant 1, size: 8 #2: Constant 2, size: 8 #3: Constant 3, size: 8 0 live-outs: [ ] Patch By: jacob.hughes@kcl.ac.uk (with heavy modification by me) Differential Revision: https://reviews.llvm.org/D59169 llvm-svn: 358324
2019-04-13 11:08:45 +08:00
CHECK-NEXT: #1: Indirect [R#6 + -44], size: 4
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 live-outs: [ ]
[StackMaps] Update llvm-readobj to parse V3 Stackmaps This updates the StackMap parser in the llvm-readobj tool to parse version 3 StackMaps, which were bumped in https://reviews.llvm.org/D32629. Version 3 StackMaps differ in that they have a uint16 sized "location size" field which was added to the Location block in a StackMap record. The record has additional padding for alignment. This was a backwards incompatible change resulting in a StackMap version bump. Patch By: jacob.hughes@kcl.ac.uk (with a rewrite of tests by me) Differential Revision: https://reviews.llvm.org/D59020 llvm-svn: 358325
2019-04-13 11:55:13 +08:00
CHECK: Record ID: 0, instruction offset: 25
[Stackmap] Added callsite counts to emitted function information. Summary: It was previously not possible for tools to use solely the stackmap information emitted to reconstruct the return addresses of callsites in the map, which is necessary to use the information to walk a stack. This patch adds per-function callsite counts when emitting the stackmap section in order to resolve the problem. Note that this slightly alters the stackmap format, so external tools parsing these maps will need to be updated. **Problem Details:** Records only store their offset from the beginning of the function they belong to. While these records and the functions are output in program order, it is not possible to determine where the end of one function's records are without the callsite count when processing the records to compute return addresses. Patch by Kavon Farvardin! Reviewers: atrick, ributzka, sanjoy Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D23487 llvm-svn: 281532
2016-09-15 04:22:03 +08:00
CHECK-NEXT: 0 locations:
CHECK-NEXT: 0 live-outs: [ ]