forced unwinding of guests has had its assumptions challenged

when forced unwinding was first envisioned, guests did not run at all
from the point they faulted. this mean that the fault address would be a
simple `guest_ctx.get_ip()` away. in the mean time, the Lucet signal
handler learning how to be crossplatform broke this assumption: it now
works by *overwriting* the guest's instruction pointer, swapping to the
guest, and letting a function run. consequently, the guest instruction
pointer is replaced and when a guest unwind is instigated after a guest
faults, the return address before `initiate_unwind` (or `unwind_stub`,
if present) will no longer be correct. libgcc_s will then fail to locate
an FDE to describe the call frame above runtime-added unwind machinery,
fail to unwind, and SIGABRT.

the solution is quite simple: since the rip-accessing code is already
handling a guest fault, we know the original faulting guest `rip` is
preserved in the fault's `details`. insted of `guest_ctx.get_ip()`, get
the address from `details.rip_addr`.

Author: iximeow

lucet-runtime/lucet-runtime-internals/src/instance.rs

@@ -1277,7 +1277,7 @@ impl Instance {
                     Ok(_) => lucet_bail!("resume with forced unwind returned normally"),
                 }
             }
-            State::Faulted { context, .. } => {
+            State::Faulted { context, details, .. } => {
                 #[unwind(allowed)]
                 extern "C" fn initiate_unwind() {
                     panic!(TerminationDetails::ForcedUnwind);
@@ -1287,7 +1287,7 @@ impl Instance {
                 context.as_ptr().save_to_context(&mut self.ctx);
 
                 // get the instruction pointer when the fault was raised
-                let guest_addr = context.as_ptr().get_ip();
+                let guest_addr = details.rip_addr;
 
                 // if we should unwind by returning into the guest to cause a fault, do so with the redzone
                 // available in case the guest was at or close to overflowing.