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/win32-eh.ll

193 lines
5.7 KiB
LLVM
Raw Normal View History

Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; RUN: llc -mtriple=i686-pc-windows-msvc < %s | FileCheck %s
declare void @may_throw_or_crash()
declare i32 @_except_handler3(...)
declare i32 @_except_handler4(...)
declare i32 @__CxxFrameHandler3(...)
declare void @llvm.eh.begincatch(i8*, i8*)
declare void @llvm.eh.endcatch()
[WinEH] Put finally pointers in the handler scope table field We were putting them in the filter field, which is correct for 64-bit but wrong for 32-bit. Also switch the order of scope table entry emission so outermost entries are emitted first, and fix an obvious state assignment bug. llvm-svn: 239574
2015-06-12 07:37:18 +08:00
declare i32 @llvm.eh.typeid.for(i8*)
define internal i32 @catchall_filt() {
ret i32 1
}
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @use_except_handler3() personality i32 (...)* @_except_handler3 {
[WinEH] Put finally pointers in the handler scope table field We were putting them in the filter field, which is correct for 64-bit but wrong for 32-bit. Also switch the order of scope table entry emission so outermost entries are emitted first, and fix an obvious state assignment bug. llvm-svn: 239574
2015-06-12 07:37:18 +08:00
entry:
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
invoke void @may_throw_or_crash()
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
to label %cont unwind label %lpad
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
cont:
ret void
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
lpad:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%cs = catchswitch within none [label %catch] unwind to caller
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
catch:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%p = catchpad within %cs [i8* bitcast (i32 ()* @catchall_filt to i8*)]
catchret from %p to label %cont
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
}
; CHECK-LABEL: _use_except_handler3:
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: pushl %ebp
; CHECK: movl %esp, %ebp
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: pushl %ebx
; CHECK: pushl %edi
; CHECK: pushl %esi
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: subl ${{[0-9]+}}, %esp
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl $-1, -16(%ebp)
; CHECK: movl $L__ehtable$use_except_handler3, -20(%ebp)
; CHECK: leal -28(%ebp), %[[node:[^ ,]*]]
; CHECK: movl $__except_handler3, -24(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %fs:0, %[[next:[^ ,]*]]
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %[[next]], -28(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[node]], %fs:0
; CHECK: calll _may_throw_or_crash
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl -28(%ebp), %[[next:[^ ,]*]]
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[next]], %fs:0
; CHECK: retl
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
; CHECK: LBB1_2: # %catch{{$}}
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
[WinEH] Add 32-bit SEH state table emission prototype This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
2015-06-10 05:42:19 +08:00
; CHECK: .section .xdata,"dr"
; CHECK-LABEL: L__ehtable$use_except_handler3:
; CHECK-NEXT: .long -1
[WinEH] Put finally pointers in the handler scope table field We were putting them in the filter field, which is correct for 64-bit but wrong for 32-bit. Also switch the order of scope table entry emission so outermost entries are emitted first, and fix an obvious state assignment bug. llvm-svn: 239574
2015-06-12 07:37:18 +08:00
; CHECK-NEXT: .long _catchall_filt
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
; CHECK-NEXT: .long LBB1_2
[WinEH] Add 32-bit SEH state table emission prototype This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
2015-06-10 05:42:19 +08:00
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @use_except_handler4() personality i32 (...)* @_except_handler4 {
[WinEH] Put finally pointers in the handler scope table field We were putting them in the filter field, which is correct for 64-bit but wrong for 32-bit. Also switch the order of scope table entry emission so outermost entries are emitted first, and fix an obvious state assignment bug. llvm-svn: 239574
2015-06-12 07:37:18 +08:00
entry:
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
invoke void @may_throw_or_crash()
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
to label %cont unwind label %lpad
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
cont:
ret void
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
lpad:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%cs = catchswitch within none [label %catch] unwind to caller
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
catch:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%p = catchpad within %cs [i8* bitcast (i32 ()* @catchall_filt to i8*)]
catchret from %p to label %cont
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
}
; CHECK-LABEL: _use_except_handler4:
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: pushl %ebp
; CHECK: movl %esp, %ebp
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: subl ${{[0-9]+}}, %esp
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %esp, -36(%ebp)
; CHECK: movl $-2, -16(%ebp)
[WinEH] Adjust the 32-bit SEH prologue to better match reality It turns out that _except_handler3 and _except_handler4 really use the same stack allocation layout, at least today. They just make different choices about encoding the LSDA. This is in preparation for lowering the llvm.eh.exceptioninfo(). llvm-svn: 238627
2015-05-30 06:57:46 +08:00
; CHECK: movl $L__ehtable$use_except_handler4, %[[lsda:[^ ,]*]]
; CHECK: xorl ___security_cookie, %[[lsda]]
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %[[lsda]], -20(%ebp)
; CHECK: leal -28(%ebp), %[[node:[^ ,]*]]
; CHECK: movl $__except_handler4, -24(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %fs:0, %[[next:[^ ,]*]]
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %[[next]], -28(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[node]], %fs:0
; CHECK: calll _may_throw_or_crash
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl -28(%ebp), %[[next:[^ ,]*]]
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[next]], %fs:0
; CHECK: retl
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
; CHECK: LBB2_2: # %catch{{$}}
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
[WinEH] Add 32-bit SEH state table emission prototype This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
2015-06-10 05:42:19 +08:00
; CHECK: .section .xdata,"dr"
; CHECK-LABEL: L__ehtable$use_except_handler4:
; CHECK-NEXT: .long -2
; CHECK-NEXT: .long 0
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4 Summary: Fix the computation of the offsets present in the scopetable when using the SEH (__except_handler4). This patch added an intrinsic to track the position of the allocation on the stack of the EHGuard. This position is needed when producing the ScopeTable. ``` struct _EH4_SCOPETABLE { DWORD GSCookieOffset; DWORD GSCookieXOROffset; DWORD EHCookieOffset; DWORD EHCookieXOROffset; _EH4_SCOPETABLE_RECORD ScopeRecord[1]; }; struct _EH4_SCOPETABLE_RECORD { DWORD EnclosingLevel; long (*FilterFunc)(); union { void (*HandlerAddress)(); void (*FinallyFunc)(); }; }; ``` The code to generate the EHCookie is added in `X86WinEHState.cpp`. Which is adding these instructions when using SEH4. ``` Lfunc_begin0: # BB#0: # %entry pushl %ebp movl %esp, %ebp pushl %ebx pushl %edi pushl %esi subl $28, %esp movl %ebp, %eax <<-- Loading FramePtr movl %esp, -36(%ebp) movl $-2, -16(%ebp) movl $L__ehtable$use_except_handler4_ssp, %ecx xorl ___security_cookie, %ecx movl %ecx, -20(%ebp) xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie movl %eax, -40(%ebp) <<-- Storing EHGuard leal -28(%ebp), %eax movl $__except_handler4, -24(%ebp) movl %fs:0, %ecx movl %ecx, -28(%ebp) movl %eax, %fs:0 movl $0, -16(%ebp) calll _may_throw_or_crash LBB1_1: # %cont movl -28(%ebp), %eax movl %eax, %fs:0 addl $28, %esp popl %esi popl %edi popl %ebx popl %ebp retl ``` And the corresponding offset is computed: ``` Luse_except_handler4_ssp$parent_frame_offset = -36 .p2align 2 L__ehtable$use_except_handler4_ssp: .long -2 # GSCookieOffset .long 0 # GSCookieXOROffset .long -40 # EHCookieOffset <<---- .long 0 # EHCookieXOROffset .long -2 # ToState .long _catchall_filt # FilterFunction .long LBB1_2 # ExceptionHandler ``` Clang is not yet producing function using SEH4, but it's a work in progress. This patch is a step toward having a valid implementation of SEH4. Unfortunately, it is not yet fully working. The EH registration block is not allocated at the right offset on the stack. Reviewers: rnk, majnemer Subscribers: llvm-commits, chrisha Differential Revision: http://reviews.llvm.org/D21231 llvm-svn: 273281
2016-06-21 23:58:55 +08:00
; CHECK-NEXT: .long -40
[WinEH] Add 32-bit SEH state table emission prototype This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
2015-06-10 05:42:19 +08:00
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long -2
[WinEH] Put finally pointers in the handler scope table field We were putting them in the filter field, which is correct for 64-bit but wrong for 32-bit. Also switch the order of scope table entry emission so outermost entries are emitted first, and fix an obvious state assignment bug. llvm-svn: 239574
2015-06-12 07:37:18 +08:00
; CHECK-NEXT: .long _catchall_filt
[SEH] Fix _except_handler4 table base states We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
2015-10-10 05:27:28 +08:00
; CHECK-NEXT: .long LBB2_2
[WinEH] Add 32-bit SEH state table emission prototype This gets all the handler info through to the asm printer and we can look at the .xdata tables now. I've convinced one small catch-all test case to work, but other than that, it would be a stretch to say this is functional. The state numbering algorithm avoids doing any scope reconstruction as we do for C++ to simplify the implementation. llvm-svn: 239433
2015-06-10 05:42:19 +08:00
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4 Summary: Fix the computation of the offsets present in the scopetable when using the SEH (__except_handler4). This patch added an intrinsic to track the position of the allocation on the stack of the EHGuard. This position is needed when producing the ScopeTable. ``` struct _EH4_SCOPETABLE { DWORD GSCookieOffset; DWORD GSCookieXOROffset; DWORD EHCookieOffset; DWORD EHCookieXOROffset; _EH4_SCOPETABLE_RECORD ScopeRecord[1]; }; struct _EH4_SCOPETABLE_RECORD { DWORD EnclosingLevel; long (*FilterFunc)(); union { void (*HandlerAddress)(); void (*FinallyFunc)(); }; }; ``` The code to generate the EHCookie is added in `X86WinEHState.cpp`. Which is adding these instructions when using SEH4. ``` Lfunc_begin0: # BB#0: # %entry pushl %ebp movl %esp, %ebp pushl %ebx pushl %edi pushl %esi subl $28, %esp movl %ebp, %eax <<-- Loading FramePtr movl %esp, -36(%ebp) movl $-2, -16(%ebp) movl $L__ehtable$use_except_handler4_ssp, %ecx xorl ___security_cookie, %ecx movl %ecx, -20(%ebp) xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie movl %eax, -40(%ebp) <<-- Storing EHGuard leal -28(%ebp), %eax movl $__except_handler4, -24(%ebp) movl %fs:0, %ecx movl %ecx, -28(%ebp) movl %eax, %fs:0 movl $0, -16(%ebp) calll _may_throw_or_crash LBB1_1: # %cont movl -28(%ebp), %eax movl %eax, %fs:0 addl $28, %esp popl %esi popl %edi popl %ebx popl %ebp retl ``` And the corresponding offset is computed: ``` Luse_except_handler4_ssp$parent_frame_offset = -36 .p2align 2 L__ehtable$use_except_handler4_ssp: .long -2 # GSCookieOffset .long 0 # GSCookieXOROffset .long -40 # EHCookieOffset <<---- .long 0 # EHCookieXOROffset .long -2 # ToState .long _catchall_filt # FilterFunction .long LBB1_2 # ExceptionHandler ``` Clang is not yet producing function using SEH4, but it's a work in progress. This patch is a step toward having a valid implementation of SEH4. Unfortunately, it is not yet fully working. The EH registration block is not allocated at the right offset on the stack. Reviewers: rnk, majnemer Subscribers: llvm-commits, chrisha Differential Revision: http://reviews.llvm.org/D21231 llvm-svn: 273281
2016-06-21 23:58:55 +08:00
define void @use_except_handler4_ssp() sspstrong personality i32 (...)* @_except_handler4 {
entry:
invoke void @may_throw_or_crash()
to label %cont unwind label %lpad
cont:
ret void
lpad:
%cs = catchswitch within none [label %catch] unwind to caller
catch:
%p = catchpad within %cs [i8* bitcast (i32 ()* @catchall_filt to i8*)]
catchret from %p to label %cont
}
; CHECK-LABEL: _use_except_handler4_ssp:
; CHECK: pushl %ebp
; CHECK: movl %esp, %ebp
; CHECK: subl ${{[0-9]+}}, %esp
; CHECK: movl %ebp, %[[ehguard:[^ ,]*]]
; CHECK: movl %esp, -36(%ebp)
; CHECK: movl $-2, -16(%ebp)
; CHECK: movl $L__ehtable$use_except_handler4_ssp, %[[lsda:[^ ,]*]]
; CHECK: xorl ___security_cookie, %[[lsda]]
; CHECK: movl %[[lsda]], -20(%ebp)
; CHECK: xorl ___security_cookie, %[[ehguard]]
; CHECK: movl %[[ehguard]], -40(%ebp)
; CHECK: leal -28(%ebp), %[[node:[^ ,]*]]
; CHECK: movl $__except_handler4, -24(%ebp)
; CHECK: movl %fs:0, %[[next:[^ ,]*]]
; CHECK: movl %[[next]], -28(%ebp)
; CHECK: movl %[[node]], %fs:0
; CHECK: calll _may_throw_or_crash
; CHECK: movl -28(%ebp), %[[next:[^ ,]*]]
; CHECK: movl %[[next]], %fs:0
; CHECK: retl
; CHECK: [[catch:[^ ,]*]]: # %catch{{$}}
; CHECK: .section .xdata,"dr"
; CHECK-LABEL: L__ehtable$use_except_handler4_ssp:
; CHECK-NEXT: .long -2
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long -40
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long -2
; CHECK-NEXT: .long _catchall_filt
; CHECK-NEXT: .long [[catch]]
Move the personality function from LandingPadInst to Function The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
2015-06-18 04:52:32 +08:00
define void @use_CxxFrameHandler3() personality i32 (...)* @__CxxFrameHandler3 {
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
invoke void @may_throw_or_crash()
to label %cont unwind label %catchall
cont:
ret void
[WinEH] Rip out the landingpad-based C++ EH state numbering code It never really worked, and the new code is working better every day. llvm-svn: 247860
2015-09-17 06:14:46 +08:00
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
catchall:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%cs = catchswitch within none [label %catch] unwind to caller
[WinEH] Rip out the landingpad-based C++ EH state numbering code It never really worked, and the new code is working better every day. llvm-svn: 247860
2015-09-17 06:14:46 +08:00
catch:
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
%p = catchpad within %cs [i8* null, i32 64, i8* null]
catchret from %p to label %cont
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
}
; CHECK-LABEL: _use_CxxFrameHandler3:
Disable FP elimination in funcs using 32-bit MSVC EH personalities The value in 'ebp' acts as an implicit argument to the outlined handlers, and is recovered with frameaddress(1). llvm-svn: 238619
2015-05-30 05:58:11 +08:00
; CHECK: pushl %ebp
; CHECK: movl %esp, %ebp
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: subl ${{[0-9]+}}, %esp
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %esp, -28(%ebp)
; CHECK: movl $-1, -16(%ebp)
; CHECK: leal -24(%ebp), %[[node:[^ ,]*]]
; CHECK: movl $___ehhandler$use_CxxFrameHandler3, -20(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %fs:0, %[[next:[^ ,]*]]
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl %[[next]], -24(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[node]], %fs:0
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl $0, -16(%ebp)
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: calll _may_throw_or_crash
[WinEH] Give up on using CSRs across 32-bit invokes for now The runtime does not restore CSRs when transferring control back to the function handling the exception. According to the experts on IRC, LLVM's register allocator has no way to model register clobbers that only happen on one edge of the CFG. For now, don't worry about trying to use the meager three CSRs available on 32-bit X86 and just say that such invokes preserve nothing. llvm-svn: 241865
2015-07-10 06:09:41 +08:00
; CHECK: movl -24(%ebp), %[[next:[^ ,]*]]
Re-land "[WinEH] Add an EH registration and state insertion pass for 32-bit x86" This reverts commit r236360. This change exposed a bug in WinEHPrepare by opting win32 code into EH preparation. We already knew that WinEHPrepare has bugs, and is the status quo for x64, so I don't think that's a reason to hold off on this change. I disabled exceptions in the sanitizer tests in r236505 and an earlier revision. llvm-svn: 236508
2015-05-06 01:44:16 +08:00
; CHECK: movl %[[next]], %fs:0
; CHECK: retl
[WinEH] Store pointers to the LSDA in the exception registration object We aren't yet emitting the LSDA yet, so this will still fail to assemble. llvm-svn: 237852
2015-05-21 07:08:04 +08:00
[WinEH] Emit EH tables for __CxxFrameHandler3 on 32-bit x86 Small (really small!) C++ exception handling examples work on 32-bit x86 now. This change disables the use of .seh_* directives in WinException when CFI is not in use. It also uses absolute symbol references in the tables instead of imagerel32 relocations. Also fixes a cache invalidation bug in MMI personality classification. llvm-svn: 238575
2015-05-30 01:00:57 +08:00
; CHECK: .section .xdata,"dr"
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK: .p2align 2
[WinEH] Emit EH tables for __CxxFrameHandler3 on 32-bit x86 Small (really small!) C++ exception handling examples work on 32-bit x86 now. This change disables the use of .seh_* directives in WinException when CFI is not in use. It also uses absolute symbol references in the tables instead of imagerel32 relocations. Also fixes a cache invalidation bug in MMI personality classification. llvm-svn: 238575
2015-05-30 01:00:57 +08:00
; CHECK-LABEL: L__ehtable$use_CxxFrameHandler3:
; CHECK-NEXT: .long 429065506
; CHECK-NEXT: .long 2
; CHECK-NEXT: .long ($stateUnwindMap$use_CxxFrameHandler3)
; CHECK-NEXT: .long 1
; CHECK-NEXT: .long ($tryMap$use_CxxFrameHandler3)
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long 0
; CHECK-NEXT: .long 1
[WinEH] Store pointers to the LSDA in the exception registration object We aren't yet emitting the LSDA yet, so this will still fail to assemble. llvm-svn: 237852
2015-05-21 07:08:04 +08:00
; CHECK-LABEL: ___ehhandler$use_CxxFrameHandler3:
; CHECK: movl $L__ehtable$use_CxxFrameHandler3, %eax
; CHECK: jmp ___CxxFrameHandler3 # TAILCALL
[WinEH] Emit .safeseh directives for all 32-bit exception handlers Use a "safeseh" string attribute to do this. You would think we chould just accumulate the set of personalities like we do on dwarf, but this fails to account for the LSDA-loading thunks we use for __CxxFrameHandler3. Each of those needs to make it into .sxdata as well. The string attribute seemed like the most straightforward approach. llvm-svn: 239448
2015-06-10 09:02:30 +08:00
; CHECK: .safeseh __except_handler3
; CHECK: .safeseh __except_handler4
; CHECK: .safeseh ___ehhandler$use_CxxFrameHandler3