Bring `IL_{Throw,Rethrow,ThrowExact}` to `PUSH_COOP_PINVOKE_FRAME` plan

[am11]

Follow up tracking issue from discussion in #116085. It will ultimately get rid of 1 of 6 remaining calls to HP-libunwind.

[am11]

cc @filipnavara, @davidwrighton

[am11]

@filipnavara (based on the comments) would it be something like this:

               ---------------------
              |  Unified Fast IL_Throw |
               ---------------------
                         ▲
             ┌───────────┴────────────┐
             │                        │
  Uses for normal         Uses in transitions from
   managed throws            unmanaged (QCall, etc)
             │                        │
     [#1] PUSH_COOP_           [#2] Delay throw until
       PINVOKE_FRAME              managed reentry
                                    │
                         [#3] Thread-local signaling
                            (à la Objective-C)

or both paths with PUSH_COOP_PINVOKE_FRAME?

[filipnavara]

I'll need to look into it again. I realized I never got the floating point context quite right. There may not be anything dependent on that in the managed unwinding but I am less sure about the odd cases and C++/CLI.

The Obj-C path will eventually go through the same path in the end. I'd prefer if it's implemented through managed throw that then flows to the unified path on the left...

[am11]

@filipnavara, here is an attempt main...am11:runtime:feature/il_throw_PUSH_COOP_PINVOKE_FRAME. You can also push changes to this branch. :)

[filipnavara]

Thanks for looking into it!

That's similar to my earlier attempt but inherits the same issue, namely that it doesn't capture the state of floating point registers. There are some architectures that depend on it and I think there were also few runtime tests failing on it. On x86 we don't unwind FP registers at all so we could ignore the detail but it's not true for other architectures.

(Aside from that I think I "inherited" SoftwareExceptionFrame from TransitionFrame to reuse the context conversion logic. That's more of a code cleanup strategy when the fundamentals are right, though.)

[am11]

Going by src/coreclr/pal/src/arch/{arch}/context2.S, all archs are using fp registers? x86 (fnsave/frstor FPU+XMM0–7), x64 (fxsave/fxrstor FP/XMM), arm (vstmia D0–31), arm64 (stp V0–31), riscv64 (fld/fsd F0–31), loongarch64 (save F0–31 FP/LSX/LASX).