RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 19:23:23 +01:00
Code Issues Projects Releases Wiki Activity
07539b2a74
llvm-mirror/test/MC/COFF/cv-def-range.s

99 lines
3.2 KiB
ArmAsm
Raw Normal View History

[MC] Add support for encoding CodeView variable definition ranges CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-02-05 02:55:49 +01:00
# RUN: llvm-mc -triple=i686-pc-win32 -filetype=obj < %s | llvm-readobj -codeview -codeview-subsection-bytes | FileCheck %s
.text
.def @feat.00;
.scl 3;
.type 0;
.endef
.globl @feat.00
@feat.00 = 1
.def _g;
.scl 2;
.type 32;
.endef
.globl _g
.p2align 4, 0x90
_g: # @g
Lfunc_begin0:
.cv_file 1 "\\usr\\local\\google\\home\\majnemer\\llvm\\src\\<stdin>"
[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-07 18:15:31 +02:00
.cv_func_id 0
[MC] Add support for encoding CodeView variable definition ranges CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-02-05 02:55:49 +01:00
.cv_loc 0 1 3 0 is_stmt 0 # <stdin>:3:0
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
subl $8, %esp
leal -4(%ebp), %eax
Lvar_begin0:
#DEBUG_VALUE: g:x <- %EAX
.cv_loc 0 1 4 7 # <stdin>:4:7
movl $0, -4(%ebp)
.cv_loc 0 1 5 3 # <stdin>:5:3
movl %eax, (%esp)
calll _f
.cv_loc 0 1 6 1 # <stdin>:6:1
Lvar_end0:
addl $8, %esp
popl %ebp
retl
Lfunc_end0:
.section .debug$T,"dr"
.long 4 # Debug section magic
.short 6 # Type record length
.short 4609 # Leaf type: LF_ARGLIST
.long 0 # Number of arguments
.short 14 # Type record length
.short 4104 # Leaf type: LF_PROCEDURE
.long 3 # Return type index
.byte 0 # Calling convention
.byte 0 # Function options
.short 0 # # of parameters
.long 4096 # Argument list type index
.short 12 # Type record length
.short 5633 # Leaf type: LF_FUNC_ID
.long 0 # Scope type index
.long 4097 # Function type
.asciz "g" # Function name
.section .debug$S,"dr"
.long 4 # Debug section magic
.long 241 # Symbol subsection for g
.long Ltmp1-Ltmp0 # Subsection size
Ltmp0:
.short Ltmp3-Ltmp2 # Record length
Ltmp2:
.short 4423 # Record kind: S_GPROC32_ID
.long 0 # PtrParent
.long 0 # PtrEnd
.long 0 # PtrNext
.long Lfunc_end0-_g # Code size
.long 0 # Offset after prologue
.long 0 # Offset before epilogue
.long 0 # Function type index
.secrel32 _g # Function section relative address
.secidx _g # Function section index
.byte 0 # Flags
.asciz "g" # Function name
Ltmp3:
.short 2 # Record length
.short 4431 # Record kind: S_PROC_ID_END
.cv_def_range Lvar_begin0 Lvar_end0, "\102\021\374\377\377\377"
[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 01:41:41 +02:00
# CHECK: DefRangeFramePointerRelSym {
[MC] Add support for encoding CodeView variable definition ranges CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-02-05 02:55:49 +01:00
# CHECK: Offset: -4
# CHECK: LocalVariableAddrRange {
# CHECK: OffsetStart: .text+0x9
# CHECK: ISectStart: 0x0
[codeview] Dump def range lengths in hex It makes it easier to correlate with assembly dumps, which are typically given with hex offsets. llvm-svn: 260619
2016-02-12 00:40:14 +01:00
# CHECK: Range: 0xF
[MC] Add support for encoding CodeView variable definition ranges CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-02-05 02:55:49 +01:00
# CHECK: }
[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 01:41:41 +02:00
# CHECK: BlockRelocations [
# CHECK: 0x4 IMAGE_REL_I386_SECREL .text
# CHECK: 0x8 IMAGE_REL_I386_SECTION .text
# CHECK: ]
[MC] Add support for encoding CodeView variable definition ranges CodeView, like most other debug formats, represents the live range of a variable so that debuggers might print them out. They use a variety of records to represent how a particular variable might be available (in a register, in a frame pointer, etc.) along with a set of ranges where this debug information is relevant. However, the format only allows us to use ranges which are limited to a maximum of 0xF000 in size. This means that we need to split our debug information into chunks of 0xF000. Because the layout of code is not known until *very* late, we must use a new fragment to record the information we need until we can know *exactly* what the range is. llvm-svn: 259868
2016-02-05 02:55:49 +01:00
# CHECK: }
Ltmp1:
.p2align 2
.cv_linetable 0, _g, Lfunc_end0
.cv_filechecksums # File index to string table offset subsection
.cv_stringtable # String table
Reference in New Issue Copy Permalink