maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/COFF/cv-inline-linetable.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

203 lines
5.7 KiB
ArmAsm
Raw Normal View History

[llvm-pdbutil] Dump inline call site line table annotations This ports and improves on some existing llvm-readobj -codeview dumping functionality that llvm-pdbutil lacked. Helpful for comparing inline line tables between MSVC and clang. llvm-svn: 362037
2019-05-30 05:26:25 +08:00
# RUN: llvm-mc -triple=i686-pc-win32 -filetype=obj %s -o %t.o
# RUN: llvm-readobj --codeview %t.o | FileCheck %s
# RUN: llvm-objdump -d %t.o | FileCheck %s --check-prefix=ASM
# RUN: llvm-pdbutil dump -symbols %t.o | FileCheck %s --check-prefix=PDB
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.text
.def @feat.00;
.scl 3;
.type 0;
.endef
.globl @feat.00
@feat.00 = 1
.def "?baz@@YAXXZ";
.scl 2;
.type 32;
.endef
.globl "?baz@@YAXXZ"
.p2align 4, 0x90
"?baz@@YAXXZ": # @"\01?baz@@YAXXZ"
Lfunc_begin0:
.cv_file 1 "D:\\src\\llvm\\build\\t.cpp"
[codeview] Add new directives to record inlined call site line info Summary: Previously we were trying to represent this with the "contains" list of the .cv_inline_linetable directive, which was not enough information. Now we directly represent the chain of inlined call sites, so we know what location to emit when we encounter a .cv_loc directive of an inner inlined call site while emitting the line table of an outer function or inlined call site. Fixes PR29146. Also fixes PR29147, where we would crash when .cv_loc directives crossed sections. Now we write down the section of the first .cv_loc directive, and emit an error if any other .cv_loc directive for that function is in a different section. Also fixes issues with discontiguous inlined source locations, like in this example: volatile int unlikely_cond = 0; extern void __declspec(noreturn) abort(); __forceinline void f() { if (!unlikely_cond) abort(); } int main() { unlikely_cond = 0; f(); unlikely_cond = 0; } Previously our tables gave bad location information for the 'abort' call, and the debugger wouldn't snow the inlined stack frame for 'f'. It is important to emit good line tables for this code pattern, because it comes up whenever an asan bug occurs in an inlined function. The __asan_report* stubs are generally placed after the normal function epilogue, leading to discontiguous regions of inlined code. Reviewers: majnemer, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24014 llvm-svn: 280822
2016-09-08 00:15:31 +08:00
.cv_func_id 0
.cv_inline_site_id 1 within 0 inlined_at 1 15 3
.cv_inline_site_id 2 within 1 inlined_at 1 10 3
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.cv_loc 0 1 13 0 is_stmt 0 # t.cpp:13:0
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
# %bb.0: # %entry
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
pushl %eax
.cv_loc 0 1 14 5 # t.cpp:14:5
addl $6, "?x@@3HC"
.cv_loc 1 1 9 5 # t.cpp:9:5
addl $4, "?x@@3HC"
.cv_loc 2 1 3 7 # t.cpp:3:7
movl $1, (%esp)
leal (%esp), %eax
.cv_loc 2 1 4 5 # t.cpp:4:5
addl %eax, "?x@@3HC"
.cv_loc 2 1 5 5 # t.cpp:5:5
addl $2, "?x@@3HC"
.cv_loc 2 1 6 5 # t.cpp:6:5
addl $3, "?x@@3HC"
.cv_loc 1 1 11 5 # t.cpp:11:5
addl $5, "?x@@3HC"
.cv_loc 0 1 16 5 # t.cpp:16:5
addl $7, "?x@@3HC"
.cv_loc 0 1 17 1 # t.cpp:17:1
popl %eax
retl
Lfunc_end0:
[llvm-pdbutil] Dump inline call site line table annotations This ports and improves on some existing llvm-readobj -codeview dumping functionality that llvm-pdbutil lacked. Helpful for comparing inline line tables between MSVC and clang. llvm-svn: 362037
2019-05-30 05:26:25 +08:00
# Check the disassembly so we have accurate instruction offsets in hex.
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
# ASM-LABEL: <?baz@@YAXXZ>:
[llvm-pdbutil] Dump inline call site line table annotations This ports and improves on some existing llvm-readobj -codeview dumping functionality that llvm-pdbutil lacked. Helpful for comparing inline line tables between MSVC and clang. llvm-svn: 362037
2019-05-30 05:26:25 +08:00
# ASM-NEXT: 0: {{.*}} pushl %eax
# ASM-NEXT: 1: {{.*}} addl $6, 0
# ASM-NEXT: 8: {{.*}} addl $4, 0
# ASM-NEXT: f: {{.*}} movl $1, (%esp)
# ASM-NEXT: 16: {{.*}} leal (%esp), %eax
# ASM-NEXT: 19: {{.*}} addl %eax, 0
# ASM-NEXT: 1f: {{.*}} addl $2, 0
# ASM-NEXT: 26: {{.*}} addl $3, 0
# ASM-NEXT: 2d: {{.*}} addl $5, 0
# ASM-NEXT: 34: {{.*}} addl $7, 0
# ASM-NEXT: 3b: {{.*}} popl %eax
# ASM-NEXT: 3c: {{.*}} retl
# PDB: S_GPROC32_ID {{.*}} `baz`
# PDB: S_INLINESITE
# PDB-NEXT: inlinee = 0x1003 (bar), parent = 0, end = 0
# PDB-NEXT: 0B08 code 0x8 (+0x8) line 0 (-0)
# PDB-NEXT: 0B27 code 0xF (+0x7) line 1 (+1)
# PDB-NEXT: 0602 line 2 (+1)
# PDB-NEXT: 031E code 0x2D (+0x1E)
# PDB-NEXT: 0407 code end 0x34 (+0x7)
# PDB: S_INLINESITE
# PDB-NEXT: inlinee = 0x1004 (foo), parent = 0, end = 0
# PDB-NEXT: 0B0F code 0xF (+0xF) line 0 (-0)
# PDB-NEXT: 0B2A code 0x19 (+0xA) line 1 (+1)
# PDB-NEXT: 0B26 code 0x1F (+0x6) line 2 (+1)
# PDB-NEXT: 0B27 code 0x26 (+0x7) line 3 (+1)
# PDB-NEXT: 0407 code end 0x2D (+0x7)
# PEB: S_INLINESITE_END
# PEB: S_INLINESITE_END
# PEB: S_PROC_ID_END
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.section .debug$T,"dr"
.long 4
.short 6
.short 4609
.long 0
.short 14
.short 4104
.asciz "\003\000\000\000\000\000\000\000\000\020\000"
.short 14
.short 5633
.asciz "\000\000\000\000\001\020\000"
.ascii "baz"
.byte 0
.short 14
.short 5633
.asciz "\000\000\000\000\001\020\000"
.ascii "bar"
.byte 0
.short 14
.short 5633
.asciz "\000\000\000\000\001\020\000"
.ascii "foo"
.byte 0
.section .debug$S,"dr"
.long 4
.long 241 # Symbol subsection for baz
.long Ltmp1-Ltmp0
Ltmp0:
.short Ltmp3-Ltmp2
Ltmp2:
.short 4423
.zero 12
.long Lfunc_end0-"?baz@@YAXXZ"
.zero 12
.secrel32 "?baz@@YAXXZ"
.secidx "?baz@@YAXXZ"
.byte 0
.ascii "baz"
.byte 0
Ltmp3:
.short Ltmp5-Ltmp4
Ltmp4:
.short 4429
[codeview] Fix inline line table accuracy for discontiguous segments After improving the inline line table dumper in llvm-pdbutil and looking at MSVC's inline line tables, it is clear that setting the length of the inlined code region does not update the code offset. This means that the delta to the beginning of a new discontiguous inlined code region should be calculated relative to the last code offset, excluding the length. Implementing this is a one line fix for MC: simply don't update LastLabel. While I'm updating these test cases, switch them to use llvm-objdump -d and llvm-pdbutil. This allows us to show offsets of each instruction and correlate the line table offsets to the actual code. llvm-svn: 362264
2019-06-01 04:55:31 +08:00
.long 0 # parent
.long 0 # end
.long 0x1003 # inlinee, bar
[codeview] Add new directives to record inlined call site line info Summary: Previously we were trying to represent this with the "contains" list of the .cv_inline_linetable directive, which was not enough information. Now we directly represent the chain of inlined call sites, so we know what location to emit when we encounter a .cv_loc directive of an inner inlined call site while emitting the line table of an outer function or inlined call site. Fixes PR29146. Also fixes PR29147, where we would crash when .cv_loc directives crossed sections. Now we write down the section of the first .cv_loc directive, and emit an error if any other .cv_loc directive for that function is in a different section. Also fixes issues with discontiguous inlined source locations, like in this example: volatile int unlikely_cond = 0; extern void __declspec(noreturn) abort(); __forceinline void f() { if (!unlikely_cond) abort(); } int main() { unlikely_cond = 0; f(); unlikely_cond = 0; } Previously our tables gave bad location information for the 'abort' call, and the debugger wouldn't snow the inlined stack frame for 'f'. It is important to emit good line tables for this code pattern, because it comes up whenever an asan bug occurs in an inlined function. The __asan_report* stubs are generally placed after the normal function epilogue, leading to discontiguous regions of inlined code. Reviewers: majnemer, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24014 llvm-svn: 280822
2016-09-08 00:15:31 +08:00
.cv_inline_linetable 1 1 9 Lfunc_begin0 Lfunc_end0
[codeview] Change readobj symbol dumping format Avoid duplicating DictScope with hand-written names everywhere. Print the S_-prefixed symbol kind for every record. This should make it easier to search for certain kinds of records when debugging PDB linking. llvm-svn: 307732
2017-07-12 07:41:41 +08:00
# CHECK: InlineSiteSym {
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
# CHECK: PtrParent: 0x0
# CHECK: PtrEnd: 0x0
# CHECK: Inlinee: bar (0x1003)
# CHECK: BinaryAnnotations [
[codeview] Add new directives to record inlined call site line info Summary: Previously we were trying to represent this with the "contains" list of the .cv_inline_linetable directive, which was not enough information. Now we directly represent the chain of inlined call sites, so we know what location to emit when we encounter a .cv_loc directive of an inner inlined call site while emitting the line table of an outer function or inlined call site. Fixes PR29146. Also fixes PR29147, where we would crash when .cv_loc directives crossed sections. Now we write down the section of the first .cv_loc directive, and emit an error if any other .cv_loc directive for that function is in a different section. Also fixes issues with discontiguous inlined source locations, like in this example: volatile int unlikely_cond = 0; extern void __declspec(noreturn) abort(); __forceinline void f() { if (!unlikely_cond) abort(); } int main() { unlikely_cond = 0; f(); unlikely_cond = 0; } Previously our tables gave bad location information for the 'abort' call, and the debugger wouldn't snow the inlined stack frame for 'f'. It is important to emit good line tables for this code pattern, because it comes up whenever an asan bug occurs in an inlined function. The __asan_report* stubs are generally placed after the normal function epilogue, leading to discontiguous regions of inlined code. Reviewers: majnemer, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24014 llvm-svn: 280822
2016-09-08 00:15:31 +08:00
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0x8, LineOffset: 0}
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0x7, LineOffset: 1}
# CHECK-NEXT: ChangeLineOffset: 1
# CHECK-NEXT: ChangeCodeOffset: 0x1E
# CHECK-NEXT: ChangeCodeLength: 0x7
# CHECK-NEXT: ]
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
# CHECK: }
Ltmp5:
.short Ltmp7-Ltmp6
Ltmp6:
.short 4429
.asciz "\000\000\000\000\000\000\000\000\004\020\000"
[codeview] Correctly handle inlining functions post-dominated by unreachable CodeView requires us to accurately describe the extent of the inlined code. We did this by grabbing the next debug location in source order and using *that* to denote where we stopped inlining. However, this is not sufficient or correct in instances where there is no next debug location or the next debug location belongs to the start of another function. To get this correct, use the end symbol of the function to denote the last possible place the inlining could have stopped at. llvm-svn: 259548
2016-02-03 03:22:34 +08:00
.cv_inline_linetable 2 1 3 Lfunc_begin0 Lfunc_end0
[codeview] Change readobj symbol dumping format Avoid duplicating DictScope with hand-written names everywhere. Print the S_-prefixed symbol kind for every record. This should make it easier to search for certain kinds of records when debugging PDB linking. llvm-svn: 307732
2017-07-12 07:41:41 +08:00
# CHECK: InlineSiteSym {
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
# CHECK: PtrParent: 0x0
# CHECK: PtrEnd: 0x0
# CHECK: Inlinee: foo (0x1004)
# CHECK: BinaryAnnotations [
[codeview] Add new directives to record inlined call site line info Summary: Previously we were trying to represent this with the "contains" list of the .cv_inline_linetable directive, which was not enough information. Now we directly represent the chain of inlined call sites, so we know what location to emit when we encounter a .cv_loc directive of an inner inlined call site while emitting the line table of an outer function or inlined call site. Fixes PR29146. Also fixes PR29147, where we would crash when .cv_loc directives crossed sections. Now we write down the section of the first .cv_loc directive, and emit an error if any other .cv_loc directive for that function is in a different section. Also fixes issues with discontiguous inlined source locations, like in this example: volatile int unlikely_cond = 0; extern void __declspec(noreturn) abort(); __forceinline void f() { if (!unlikely_cond) abort(); } int main() { unlikely_cond = 0; f(); unlikely_cond = 0; } Previously our tables gave bad location information for the 'abort' call, and the debugger wouldn't snow the inlined stack frame for 'f'. It is important to emit good line tables for this code pattern, because it comes up whenever an asan bug occurs in an inlined function. The __asan_report* stubs are generally placed after the normal function epilogue, leading to discontiguous regions of inlined code. Reviewers: majnemer, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24014 llvm-svn: 280822
2016-09-08 00:15:31 +08:00
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0xF, LineOffset: 0}
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0xA, LineOffset: 1}
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0x6, LineOffset: 1}
# CHECK-NEXT: ChangeCodeOffsetAndLineOffset: {CodeOffset: 0x7, LineOffset: 1}
# CHECK-NEXT: ChangeCodeLength: 0x7
# CHECK-NEXT: ]
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
# CHECK: }
Ltmp7:
.short 2
.short 4430
[codeview] Wire up the .cv_inline_linetable directive This directive emits the binary annotations that describe line and code deltas in inlined call sites. Single-stepping through inlined frames in windbg now works. llvm-svn: 259535
2016-02-03 01:41:18 +08:00
# CHECK: InlineSiteEnd {
# CHECK: }
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.short 2
.short 4430
[codeview] Wire up the .cv_inline_linetable directive This directive emits the binary annotations that describe line and code deltas in inlined call sites. Single-stepping through inlined frames in windbg now works. llvm-svn: 259535
2016-02-03 01:41:18 +08:00
# CHECK: InlineSiteEnd {
# CHECK: }
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.short 2
.short 4431
Ltmp1:
[codeview] Wire up the .cv_inline_linetable directive This directive emits the binary annotations that describe line and code deltas in inlined call sites. Single-stepping through inlined frames in windbg now works. llvm-svn: 259535
2016-02-03 01:41:18 +08:00
.p2align 2
[CodeView] Implement .cv_inline_linetable This support is _very_ rudimentary, just enough to get some basic data into the CodeView debug section. Left to do is: - Use the combined opcodes to save space. - Do something about code offsets. llvm-svn: 259230
2016-01-30 03:24:12 +08:00
.cv_linetable 0, "?baz@@YAXXZ", Lfunc_end0
.cv_filechecksums # File index to string table offset subsection
.cv_stringtable # String table
[CodeView] Add line numbers for inlined call sites We did this for inline call site line tables, but we hadn't done it for regular function line tables yet. This patch copies that logic from encodeInlineLineTable. llvm-svn: 322905
2018-01-19 06:55:43 +08:00
# CHECK-LABEL: FunctionLineTable [
# CHECK: LinkageName: ?baz@@YAXXZ
# CHECK: Flags: 0x1
# CHECK: CodeSize: 0x3D
# CHECK: FilenameSegment [
# CHECK: Filename: D:\src\llvm\build\t.cpp (0x0)
# CHECK: +0x0 [
# CHECK: LineNumberStart: 13
# CHECK: ]
# CHECK: +0x1 [
# CHECK: LineNumberStart: 14
# CHECK: ]
# CHECK: +0x8 [
# CHECK: LineNumberStart: 15
# CHECK: ]
# There shouldn't be any other line number entries because all the other
# .cv_locs are on line 15 where the top-level inline call site is.
# CHECK-NOT: LineNumberStart
# CHECK: +0x34 [
# CHECK: LineNumberStart: 16
# CHECK: ]
# CHECK: +0x3B [
# CHECK: LineNumberStart: 17
# CHECK: ]
# CHECK: ]
# CHECK: ]