Stream: wg-ffi-unwind

Topic: Native frame definition


gnzlbg (Oct 16 2019 at 19:16, on Zulip):

For calling a function following the “native” platform ABI, there are often many constraints imposed by the platform.

For example, if the platform ABI is a C ABI, there is often the concept of a contiguous stack, with stack frames, which have to satisfy an ABI.

This causes problems, for example, when Go calls into C, it needs to copy its segmented stacks into a contiguous stack, which has some cost.

By “native” frames, I was referring to how the platform defines frames for its ABI. Same for unwinding, and the call ABI. Those are the constraints that must be satisfied when interfacing with the OS kernel, etc.

nikomatsakis (Oct 16 2019 at 19:36, on Zulip):

Makes sense. I'm not sure what this is in reference to, though :)

Adam C. Foltzer (Oct 16 2019 at 20:15, on Zulip):

I think this could come into play for trying to unwind frames that lack call frame information

Adam C. Foltzer (Oct 16 2019 at 20:15, on Zulip):

we basically have a segmented stack on Lucet, though, and while it's tricky to write the CFI to wire up the pieces of the different stacks, it works without having to do any copying

gnzlbg (Oct 17 2019 at 08:59, on Zulip):

Oh sorry, this was me branching @acfoltzer comment from the other thread into its own discussion: https://rust-lang.zulipchat.com/#narrow/stream/210922-wg-ffi-unwind/topic/lucent.20use.20case/near/178318996

gnzlbg (Oct 17 2019 at 09:02, on Zulip):

So if we agree on what native frames are, then we just need to agree on what Rust frames are, and then we can see what's going on there.

gnzlbg (Oct 17 2019 at 09:03, on Zulip):

For example, if you use Rust to compile WASM and that WASM to emit a native frame, is that native frame a Rust frame of the same kind that if you just go from Rust to native on that platform ?

gnzlbg (Oct 17 2019 at 09:03, on Zulip):

Or if like weld you just have LLVM-IR and emit a native frame, is that a Rust native frame ?

gnzlbg (Oct 17 2019 at 09:04, on Zulip):

I think that a reasonable way to say what Rust native frames are would be to say that "they are frames generated by the Rust toolchain"

gnzlbg (Oct 17 2019 at 09:04, on Zulip):

Since weld and lucet are different toolchains, the frames they generate aren't Rust frames.

gnzlbg (Oct 17 2019 at 09:05, on Zulip):

That is, if lucet wasm "unwinds", that exception should be foreign in Rust

gnzlbg (Oct 17 2019 at 09:05, on Zulip):

and if lucet Rust unwinds through a "lucet-wasm native frame" back into Rust, then the Rust panic should be foreign in the "lucet wasm native frame"

gnzlbg (Oct 17 2019 at 09:07, on Zulip):

However, I can imagine that for lucet's application it might make sense to allow those "lucet-wasm native frames" to handle Rust panics as non-foreign

acfoltzer (Oct 17 2019 at 16:42, on Zulip):

Yep, you've got it right. "Rust frames" to me are only those frames for functions emitted by rustc; the fact that the Lucet and Weld compilers are implemented in Rust is incidental

However, I can imagine that for lucet's application it might make sense to allow those "lucet-wasm native frames" to handle Rust panics as non-foreign

This isn't in our future plans. The only reason the wasm frames might need to have more than just .eh_frame information is if we choose native unwinding as the means to support the Wasm exceptions proposal. In this case, Wasm would be treated as its own language for, e.g., the exceptionClass field in the ABI. If we needed to unwind from a Rust frame such that the Wasm frames would be able to catch it, we would use _RaiseException with a custom-made exception object rather than using a Rust panic

gnzlbg (Oct 17 2019 at 16:45, on Zulip):

@acfoltzer makes sense - Can those WASM exceptions unwinding out-of-wasm into rust ?

acfoltzer (Oct 17 2019 at 16:46, on Zulip):

they would be able to, but again this is a double-hypothetical that 1. the Wasm exceptions proposal is accepted and 2. we choose to use native unwinding to implement it

acfoltzer (Oct 17 2019 at 16:46, on Zulip):

but one could imagine Rust -> Wasm (catches) -> Rust -> Wasm (throws)

acfoltzer (Oct 17 2019 at 16:47, on Zulip):

what I can't imagine happening is a Wasm exception unwinding out to the outermost frames outside the initial call to the guest, since that would be analogous to an exception unwinding beyond the entrypoint of a normal program

acfoltzer (Oct 17 2019 at 16:48, on Zulip):

we would always want to catch that case and return a GuestUnhandledException error to the runtime user or something along those lines

gnzlbg (Oct 17 2019 at 17:02, on Zulip):

but one could imagine Rust -> Wasm (catches) -> Rust -> Wasm (throws)

That's what I was referring to. This would require supporting unwinding Rust frames with foreign exceptions

gnzlbg (Oct 17 2019 at 17:03, on Zulip):

I'm going to take a look at the WASM exception proposal, this might be relevant for WASI

Kyle Strand (Oct 22 2019 at 00:40, on Zulip):

@acfoltzer @nikomatsakis @gnzlbg

I'm finally reading Niko's RFC draft, and it's pushing me towards avoiding the phrase "native frames" entirely. I think we should refer to "Rust frames" and "foreign frames", which is more explicit and lines up with the F for "foreign" in "cross-FFI unwinding".

Kyle Strand (Oct 22 2019 at 00:41, on Zulip):

(One thing that led me to this conclusion is that in many cases we've been saying "native" where we mean "foreign", and those are _very odd_ words to treat synonymously!)

Kyle Strand (Oct 22 2019 at 00:41, on Zulip):

"Native" as a descriptor should, I think, only be used to refer to the "native unwinding mechanism" or other details of the platform-provided ABI.

Kyle Strand (Oct 22 2019 at 00:42, on Zulip):

("Foreign" also has a connection to the Itanium ABI spec, which refers to "foreign exceptions.")

nikomatsakis (Oct 28 2019 at 20:15, on Zulip):

I'm finally reading Niko's RFC draft, and it's pushing me towards avoiding the phrase "native frames" entirely. I think we should refer to "Rust frames" and "foreign frames", which is more explicit and lines up with the F for "foreign" in "cross-FFI unwinding".

seems good, btw

Last update: Nov 15 2019 at 10:30UTC