Stream: wg-ffi-unwind

Topic: lucent use case


nikomatsakis (Oct 16 2019 at 10:13, on Zulip):

@Adam C. Foltzer can confirm, but from what I understand, the lucent use case is that they have:

I think this is a good "first target" to fully define. First question @Adam C. Foltzer is whether I have all the details right.

Next question is whether there are other pertinent details I've omitted.

What would be helpful (I think) would be to get some kind of presentation of what the minimum set of details we would have to specify in order to make that behavior stable and well-defined. I imagine @gnzlbg you have some handle on that.

gnzlbg (Oct 16 2019 at 12:05, on Zulip):

@nikomatsakis IIRC, one detail was that those native frames are actually / often written in Rust, but there are many reasons why lucent cannot use the Rust ABI (too unstable, etc.).

gnzlbg (Oct 16 2019 at 12:06, on Zulip):

I imagine @gnzlbg you have some handle on that.

I believe the proposal in my PR solves that problem without any undefined behavior on all Itanium-like targets (most Rust targets, except for windows ones).

gnzlbg (Oct 16 2019 at 12:08, on Zulip):

The proposal does not contain any wording for the windows targets yet though.

Also, if those native frames are indeed written in Rust, then lucent would be a good example for an application that might need the feature proposed in the "Futures section"

gnzlbg (Oct 16 2019 at 12:08, on Zulip):

To avoid paying any "unwind translation" costs if we were to introduce any in the future

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

Hm, avoiding translation costs seems like a future optimization that may or may not be useful enough to pursue - I suspect that a translation layer may just be the cost of cross-platform stability

nikomatsakis (Oct 16 2019 at 16:41, on Zulip):

I believe the proposal in my PR solves that problem without any undefined behavior on all Itanium-like targets (most Rust targets, except for windows ones).

yeah, it may very well -- that'd be great

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

(actually, let's not even get into that right now, and just leave it at "possibly useful feature described in Futures section")

nikomatsakis (Oct 16 2019 at 16:42, on Zulip):

Also, if those native frames are indeed written in Rust, then lucent would be a good example for an application that might need the feature proposed in the "Futures section"

maybe so, but no need to worry about that now

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

Those native frames have no destructors

I believe last time we spoke to Adam, he said that they definitely do need to handle frames with destructors

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

(Which should not necessarily impact our decision of what an "MVP" looks like)

Adam C. Foltzer (Oct 16 2019 at 18:57, on Zulip):

This largely sounds right to me, but I think it's worth digging into what "native frames" mean. We have at least two source languages for frames in Lucet apps: Rust, and Wasm (compiled into x86-64). the runtime system is in Rust, and in practice so is the implementation of the functions Wasm guests import (we call those hostcalls).

When you just run a Wasm guest that does some computation and returns without calling a hostcall, your most complicated call chain looks like Rust -> Wasm.

It gets trickier when you start calling hostcalls, because then you can have Rust -> Wasm -> Rust. It really gets interesting when you learn that hostcalls can call back into Wasm, so you can actually chain them alternately indefinitely: Rust -> Wasm -> Rust -> Wasm -> [...].

We want to uphold the property that destructors run on any Rust frames that may exist when there's either a panic in a Rust hostcall, or when the Wasm guest code faults. Whether the Wasm frames get unwound or just dropped is irrelevant at this point, because as Niko mentioned there are no destructors on those frames, just enough call frame information to let the unwinder do its thing.

Adam C. Foltzer (Oct 16 2019 at 19:03, on Zulip):

@gnzlbg I'll have to give your PR a thorough read later this afternoon, but it looks promising. the one thing I'd point out based on your comments here is that the "native" frames in the Lucet use case are generated from Wasm, not Rust. I believe Weld generates their code from LLVM, so "native" for them also means non-Rust

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

when I wrote native I meant "generated from wasm"

acfoltzer (Oct 16 2019 at 20:41, on Zulip):

on a meta note, I'm going to be in "omg we have to get a demo out by when?" mode until mid-November. I am still able to make time for this effort, particularly if any of y'all have a specific ask, but I will not be able to check in as frequently to do proactive work on stuff. If there are pieces missing that I'd be the right contributor to provide, please let me know so I don't miss them when I'm catching up on a batch of comments

Kyle Strand (Oct 16 2019 at 20:42, on Zulip):

@acfoltzer Is the unavailability of an MVP for cross-language unwinding blocking your November demo work?

acfoltzer (Oct 16 2019 at 20:43, on Zulip):

it is not; we are on nightly now and using #[unwind(allowed)]

Kyle Strand (Oct 16 2019 at 20:45, on Zulip):

Okay, glad there's no pressure from that direction, then!

acfoltzer (Oct 16 2019 at 20:59, on Zulip):

yeah, we're using async/await for the demo anyway, so it's not much extra cost at this point

Kyle Strand (Oct 16 2019 at 21:04, on Zulip):

Well, that's at least on Beta :)

acfoltzer (Oct 16 2019 at 21:05, on Zulip):

right, now it is, at long last :)

Last update: Nov 15 2019 at 10:05UTC