Ensure the personality does not panic

[Noratrieb]

In a cdylib that uses std and is free from panics in the code, the panic machinery will still be pulled in because of the personality function when using LLD.

The personality function is used by unwinding to figure out what to do when unwinding through a function. Each function that participates in unwind has an associated FDE (frame descriptor entries) in .eh_frame. This FDE points to a CIE (common information entry), which can reference a language-specific personality function, like rust_eh_personality in our case.

As long as there is a CIE that references the personality, the function cannot be removed. If all references to a CIE get removed (because the functions and their associated FDEs have been removed), LLD will not remove the CIE, likely due to the ordering of its passes). Binutils ld will remove it.

In the case where the CIE is still around (despite not being used), it will still reference the personality function, so that will still be around. This is not great since it's a bunch of code, but also not that much. But this is where panicking comes in.

Before this change, the personality function internally made use of dyn Fn. This caused an indirect call that LLVM was not able to analyze as guaranteed free of unwinding, even during fat LTO. This meant that an invoke was used, with a landing pad. In an extern "C" function, which the personality function is, all landing pads call panic_cannot_unwind, which is a panic_nounwind, which is, obviously, a panic. And as a panic, it pulls in all the panic machinery, which is very big and sad.

It is also completely unnecessary, because these indirect functions do not panic, as they are just a convenient abstraction provided from the outside. By restructuring the code to remove these indirect calls, LLVM is able to fully analyze everything and see that rust_eh_personality cannot panic, and therefore remove its landing pad.

With this change, exporting a panic-free function from a cdylib will only contain the function and the personality (when linked with LLD at least, with binutils ld it will only contain the function), with no panic code being present at all, which is great.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

I'll open an LLD issue for this, since this doesn't seem quite right from all I found, but I think it's still useful to ensure this here.

[rust-log-analyzer]

The job pr-check-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] hashbrown test:false 1.367
error[E0412]: cannot find type `_Unwind_Context` in crate `unwind`
  --> library/std/src/sys/personality/dwarf/eh.rs:43:42
   |
43 |     pub(crate) raw_context: *mut unwind::_Unwind_Context,
   |                                          ^^^^^^^^^^^^^^^ not found in `unwind`

error[E0425]: cannot find function `_Unwind_GetTextRelBase` in crate `unwind`
   --> library/std/src/sys/personality/dwarf/eh.rs:243:46
    |
243 |         DW_EH_PE_textrel => unsafe { unwind::_Unwind_GetTextRelBase(context.raw_context) },
    |                                              ^^^^^^^^^^^^^^^^^^^^^^ not found in `unwind`

error[E0425]: cannot find function `_Unwind_GetDataRelBase` in crate `unwind`
   --> library/std/src/sys/personality/dwarf/eh.rs:244:46
    |
244 |         DW_EH_PE_datarel => unsafe { unwind::_Unwind_GetDataRelBase(context.raw_context) },
    |                                              ^^^^^^^^^^^^^^^^^^^^^^ not found in `unwind`

Some errors have detailed explanations: E0412, E0425.
For more information about an error, try `rustc --explain E0412`.
[RUSTC-TIMING] std test:false 5.470