Disable ARM EHABI when building without landing pads

[bharrisau]

I'm not sure if/how to test this. Passes make check.

Before

  .globl  _ZN4char8from_u3219h816af907f1240ba2a94v0.0E
  .align  2
  .type _ZN4char8from_u3219h816af907f1240ba2a94v0.0E,%function
_ZN4char8from_u3219h816af907f1240ba2a94v0.0E:
  .fnstart
.Leh_func_begin0:
  push  {r4, r5}
  mov r5, sp
...
.LBB0_5:                                                                                                                                                                                                            
  pop {r4, r5}                                                                                                                                                                                                      
  .save {r11, lr}                                                                                                                                                                                                   
  push  {r11, lr}                                                                                                                                                                                                   
  .setfp  r11, sp                                                                                                                                                                                                   
  mov r11, sp                                                                                                                                                                                                       
  .pad  #24                                                                                                                                                                                                         
  sub sp, sp, #24                                                                                                                                                                                                   
  ldr r2, .LCPI0_3                                                                                                                                                                                                  
.LPC0_0:
...
Ltmp0:
  .size _ZN4char8from_u3219h816af907f1240ba2a94v0.0E, .Ltmp0--ZN4char8from_u3219h816af907f1240ba2a94v0.0E
.Leh_func_end0:
  .fnend

After

  .globl  _ZN4char8from_u3219h816af907f1240ba2a94v0.0E
  .align  2
  .type _ZN4char8from_u3219h816af907f1240ba2a94v0.0E,%function
_ZN4char8from_u3219h816af907f1240ba2a94v0.0E:
  push  {r4, r5}
  mov r5, sp
...
.LBB0_5:
  pop {r4, r5}
  push  {r11, lr}
  mov r11, sp
  sub sp, sp, #24
  ldr r2, .LCPI0_3
.LPC0_0:
...
.Ltmp0:
  .size _ZN4char8from_u3219h816af907f1240ba2a94v0.0E, .Ltmp0-_ZN4char8from_u3219h816af907f1240ba2a94v0.0E

[bharrisau]

Saw this mentioned in #10942

[alexcrichton]

I think it generally makes sense that the behavior is undefined if you run with -Z no-landing-pads. Feel free to xfail-android the test.

[alexcrichton]

Ah, what I meant to say is that behavior is undefined if you unwind in code built with -Z no-landing-pads

[bharrisau]

Yeah, but I didn't think it should be even trying to unwind. I'll admit to not being sure of the intent behind the no-landing-pads switch. Is saying that exceptions with no-landing-pads gives undefined behaviour all right? It looks like the X86 code just doesn't call destructors (I'm not sure if that is better or worse than trying to execute arbitrary code).

[alexcrichton]

We call a "landing pad" a segment of code which is run whenever an unwinding happens. This means that after some function was called, something down in the call stack ended up calling fail!() triggering an unwinding of the stack. Each call instruction in a function may trigger unwinding, and is then associated with a landing pad. These landing pads are what run destructors when the stack unwinds.

With the -Z no-landing-pads switch, none of these landing pads are generated. They end up calling special functions in the libunwind library which may not be present on all platforms.

On ARM, it looks like the codegen is so different that if the code isn't built to have exceptions thrown that there's no way for libunwind to unwind the stack when an exception is thrown. I suppose it doesn't affect x86 and x86_64 codegen that much.

I was basically trying to think of a way to test that -Z no-landing-pads actually works (it was broken recently), so that's what this test is doing. The behavior is ARM-specific (from what I believe), so I think it's ok to just ignore it on android.

[bharrisau]

Ahh, got you. Your test is making sure that it is behaving incorrectly, as opposed to correctly behaving unsafely. Well, if "undefined" is sufficient I'll xfail the test for android (just wish it failed more concretely than with an illegal instruction).

[alexcrichton]

Upon rebasing LLVM it sounds like they're removing the arm-enable-ehabi option entirely. I think they turned it on by default for relevant platforms and I suppose they handle it somehow for others. See llvm-mirror/llvm@3fca788

I'm just waiting for LLVM's mingw bots to go green before we rebase and take an LLVM upgrade, but it could be a long time before that happens if they start requiring c++11 to build llvm (which they're definitely doing soon).

[alexcrichton]

Closing in favor of #12207 (llvm removed these options).