maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/empty-functions.ll

45 lines
1.4 KiB
LLVM
Raw Normal View History

Consider this function: void foo() { __builtin_unreachable(); } It will output the following on Darwin X86: _func1: Leh_func_begin0: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: Leh_func_end0: This prolog adds a new Call Frame Information (CFI) row to the FDE with an address that is not within the address range of the code it describes -- part is equal to the end of the function -- and therefore results in an invalid EH frame. If we emit a nop in this situation, then the CFI row is now within the address range. llvm-svn: 108568
2010-07-17 06:51:10 +08:00
; RUN: llc < %s -mtriple=x86_64-apple-darwin | FileCheck -check-prefix=CHECK-NO-FP %s
; RUN: llc < %s -mtriple=x86_64-apple-darwin -disable-fp-elim | FileCheck -check-prefix=CHECK-FP %s
Fix a lot of confusion around inserting nops on empty functions. On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
2014-09-16 02:32:58 +08:00
; RUN: llc < %s -mtriple=x86_64-linux-gnu | FileCheck -check-prefix=LINUX-NO-FP %s
; RUN: llc < %s -mtriple=x86_64-linux-gnu -disable-fp-elim | FileCheck -check-prefix=LINUX-FP %s
Consider this function: void foo() { __builtin_unreachable(); } It will output the following on Darwin X86: _func1: Leh_func_begin0: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: Leh_func_end0: This prolog adds a new Call Frame Information (CFI) row to the FDE with an address that is not within the address range of the code it describes -- part is equal to the end of the function -- and therefore results in an invalid EH frame. If we emit a nop in this situation, then the CFI row is now within the address range. llvm-svn: 108568
2010-07-17 06:51:10 +08:00
define void @func() {
entry:
unreachable
}
Fix a lot of confusion around inserting nops on empty functions. On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
2014-09-16 02:32:58 +08:00
; MachO cannot handle an empty function.
Consider this function: void foo() { __builtin_unreachable(); } It will output the following on Darwin X86: _func1: Leh_func_begin0: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: Leh_func_end0: This prolog adds a new Call Frame Information (CFI) row to the FDE with an address that is not within the address range of the code it describes -- part is equal to the end of the function -- and therefore results in an invalid EH frame. If we emit a nop in this situation, then the CFI row is now within the address range. llvm-svn: 108568
2010-07-17 06:51:10 +08:00
; CHECK-NO-FP: _func:
Don't produce a __debug_frame. I tested both gdb on a bootstrapped clang and and the gdb testsuite on OS X (snow leopard) and both are happy using __eh_frame. llvm-svn: 130937
2011-05-06 02:43:39 +08:00
; CHECK-NO-FP-NEXT: .cfi_startproc
Consider this function: void foo() { __builtin_unreachable(); } It will output the following on Darwin X86: _func1: Leh_func_begin0: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: Leh_func_end0: This prolog adds a new Call Frame Information (CFI) row to the FDE with an address that is not within the address range of the code it describes -- part is equal to the end of the function -- and therefore results in an invalid EH frame. If we emit a nop in this situation, then the CFI row is now within the address range. llvm-svn: 108568
2010-07-17 06:51:10 +08:00
; CHECK-NO-FP: nop
Don't produce a __debug_frame. I tested both gdb on a bootstrapped clang and and the gdb testsuite on OS X (snow leopard) and both are happy using __eh_frame. llvm-svn: 130937
2011-05-06 02:43:39 +08:00
; CHECK-NO-FP-NEXT: .cfi_endproc
Consider this function: void foo() { __builtin_unreachable(); } It will output the following on Darwin X86: _func1: Leh_func_begin0: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: Leh_func_end0: This prolog adds a new Call Frame Information (CFI) row to the FDE with an address that is not within the address range of the code it describes -- part is equal to the end of the function -- and therefore results in an invalid EH frame. If we emit a nop in this situation, then the CFI row is now within the address range. llvm-svn: 108568
2010-07-17 06:51:10 +08:00
; CHECK-FP: _func:
Don't produce a __debug_frame. I tested both gdb on a bootstrapped clang and and the gdb testsuite on OS X (snow leopard) and both are happy using __eh_frame. llvm-svn: 130937
2011-05-06 02:43:39 +08:00
; CHECK-FP-NEXT: .cfi_startproc
; CHECK-FP-NEXT: :
; CHECK-FP-NEXT: pushq %rbp
; CHECK-FP-NEXT: .cfi_def_cfa_offset 16
Use the dwarf->llvm mapping to print register names in the cfi directives. Fixes PR9826. llvm-svn: 132317
2011-05-31 04:20:15 +08:00
; CHECK-FP-NEXT: .cfi_offset %rbp, -16
Don't produce a __debug_frame. I tested both gdb on a bootstrapped clang and and the gdb testsuite on OS X (snow leopard) and both are happy using __eh_frame. llvm-svn: 130937
2011-05-06 02:43:39 +08:00
; CHECK-FP-NEXT: movq %rsp, %rbp
; CHECK-FP-NEXT: .cfi_endproc
Fix a lot of confusion around inserting nops on empty functions. On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
2014-09-16 02:32:58 +08:00
; An empty function is perfectly fine on ELF.
; LINUX-NO-FP: func:
; LINUX-NO-FP-NEXT: .cfi_startproc
; LINUX-NO-FP-NEXT: {{^}}#
; LINUX-NO-FP-NEXT: {{^}}.L{{.*}}:{{$}}
; LINUX-NO-FP-NEXT: .size func, .L{{.*}}-func
; LINUX-NO-FP-NEXT: .cfi_endproc
Don't emit CFI instructions at the end of a function When functions are terminated by unreachable instructions, the last instruction might trigger a CFI instruction to be generated. However, emitting it would be be illegal since the function (and thus the FDE the CFI is in) has already ended with the previous instruction. Darwin's dwarfdump --verify --eh-frame complains about this and the specification supports this. Relevant bits from the DWARF 5 standard (6.4 Call Frame Information): "[The] address_range [field in an FDE]: The number of bytes of program instructions described by this entry." "Row creation instructions: [...] The new location value is always greater than the current one." The first quotation implies that a CFI cannot describe a target address outside of the enclosing FDE's range. rdar://problem/26244988 Differential Revision: https://reviews.llvm.org/D32246 llvm-svn: 301219
2017-04-25 02:45:59 +08:00
; A cfi directive cannot point to the end of a function.
Fix a lot of confusion around inserting nops on empty functions. On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
2014-09-16 02:32:58 +08:00
; LINUX-FP: func:
; LINUX-FP-NEXT: .cfi_startproc
; LINUX-FP-NEXT: {{^}}#
; LINUX-FP-NEXT: pushq %rbp
; LINUX-FP-NEXT: .cfi_def_cfa_offset 16
; LINUX-FP-NEXT: .cfi_offset %rbp, -16
; LINUX-FP-NEXT: movq %rsp, %rbp
; LINUX-FP-NEXT:{{^}}.L{{.*}}:{{$}}
Use the vanilla func_end symbol for .size. No need to create yet another temp symbol. llvm-svn: 231198
2015-03-04 09:35:23 +08:00
; LINUX-FP-NEXT: .size func, .Lfunc_end0-func
Fix a lot of confusion around inserting nops on empty functions. On MachO, and MachO only, we cannot have a truly empty function since that breaks the linker logic for atomizing the section. When we are emitting a frame pointer, the presence of an unreachable will create a cfi instruction pointing past the last instruction. This is perfectly fine. The FDE information encodes the pc range it applies to. If some tool cannot handle this, we should explicitly say which bug we are working around and only work around it when it is actually relevant (not for ELF for example). Given the unreachable we could omit the .cfi_def_cfa_register, but then again, we could also omit the entire function prologue if we wanted to. llvm-svn: 217801
2014-09-16 02:32:58 +08:00
; LINUX-FP-NEXT: .cfi_endproc