Stream: git-wasmtime

Topic: wasmtime / PR #1216 Windows fprs preservation

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:05):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:05):

iximeow created PR Review Comment:

The frame offset is currently being incorrectly stored as 0 in our unwind information (the only ops used until now didn't require it, luckily).

I'll have to check in on this too.. Broadly this does make sense, yes. I looked at what I think is the reference for the diagram you included here - do you know how preparing for a the call to B interacts with unwind information? Does Windows require we reserve enough space for the most stack-heavy function call as part of the frame's fixed allocation? (I'm not totally certain we do that, and I'd want to double-check that too)

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:07):

iximeow edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:30):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:30):

peterhuene created PR Review Comment:

Yes, Windows does require that the local frame's fixed allocation have the maximum amount of space required for passing arguments on the stack for all function calls made by the function, plus 32 bytes for the shadow space which should always be RSP+0x8 to RSP+0x20 upon entry to the callee.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:33):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:34):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:42):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:42):

peterhuene created PR Review Comment:

Regarding how calling B interacts with the unwind information, it doesn't. Unwind only concerns itself with unwinding the operations done in the prologue, therefore it is only interested in the register save space and not where any arguments for callees might be stored. RSP should not adjust (except by a call) after the frame is established unless it's a "dynamic" (alloca) frame, at which point a frame pointer must be used. Since we're using a frame pointer anyway, we also need that "frame pointer offset" adjustment so that it unwinds from the right base.

What I don't get is why frames with a frame pointer need to be described using this "base address" rather than just treating every unwind operation offset as negative from the frame pointer when there is one and positive from RSP when there is not. This seems unnecessarily complicated, but I'm sure there's a good reason.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:42):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:46):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 19:46):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 20:48):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 05 2020 at 20:48):

iximeow created PR Review Comment:

Great, I think we're on the same page now. I really appreciate your help in figuring this out.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 06 2020 at 00:28):

iximeow edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 18:19):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 18:38):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 18:38):

iximeow created PR Review Comment:

I've finally gotten another tweak that I _think_ makes for the right unwind information. Because we always set up rbp at the start of the function we're kind of limited to producing functions that have a static frame size of 256 or fewer bytes, and unwinding information is requested. I included some checks about this, and because we can get away with a wrong offset so long as no unwind codes need it, this can be scoped down to only impacting functions using callee-save FPRs.

This turns what is a (still open) miscompile corrupting arbitrary caller state into a compiler panic, so I think adding a panic here is still a net improvement.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 18:53):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 19:20):

peterhuene created PR Review Comment:

Why is the static frame size limited to 256 bytes? The unwind information should only place limits on the offset from the frame pointer to the "base" (i.e. register save area) and not the entire frame size, no?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 19:20):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 19:23):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:19):

iximeow created PR Review Comment:

Since the callee-save region is added after spill slots, it ends up on the lower side of the stack frame, so we need an offset that covers locals and spills, then callee-save FPRs. I fiddled with stack_layout a bit to try keeping callee-save FPRs at the higher side of the stack frame (like the diagram shows) but I couldn't figure out how to get that to work.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:19):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:22):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:32):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:32):

peterhuene created PR Review Comment:

Ugh. It sounds like we really need to address how we lay out frames in Cranelift if this is a self-imposed limitation.

I mean we can live with this limitation as a short-term stop gap to get the more important issue of not saving the FPRs (i.e. unblock this PR), but I think we should file a high-priority issue to remove this limitation by always saving registers at higher addresses in the frame than any locals and spills.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:33):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:52):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:52):

peterhuene created PR Review Comment:

This seems incomplete.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:55):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 20:55):

iximeow created PR Review Comment:

I was only particularly concerned with verifying that xmm15 ends up with an offset that doesn't overlap with shadow space or stack argument space for the called function. I can include the rest of the function's UnwindCode if you'd like, but I figured that got outside the point of this test.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 21:05):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 21:05):

peterhuene created PR Review Comment:

I'm good with this but perhaps with a comment explaining why only the first unwind code is validated?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 21:56):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 23:22):

bjorn3 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 23:22):

bjorn3 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2020 at 23:22):

bjorn3 created PR Review Comment:

This is always true when reached.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 07:56):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 08:00):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 08:00):

iximeow created PR Review Comment:

Yes, this is back to being somewhat wip - wasmtime yielded some new errors I hadn't seen testing only in cranelift. I'd tried setting up a build environment on the Windows machine I have available but ran afoul of link.exe being... wrong? So I just added a bit of logging in the hopes I could figure out what went wrong from just a bit of CI logs. I think I have, and once it's passing I'm going to revert 29c6c40 .

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 17:43):

pchickey updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2020 at 17:43):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:09):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:18):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:20):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:20):

iximeow created PR Review Comment:

I've made the FPR stack slot an ExplicitSlot rather than SpillSlot because there _is_ some mention of SpillSlot being eligible for certain optimizations in redundant_reload_remover. There shouldn't be redundant reloads from this slot, but ExplicitSlot specifically indicates its use for stack_load/stack_store, which are the intended result of this PR (only not using those here because of encoding constraints that need to be fixed)

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:21):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:21):

iximeow created PR Review Comment:

Done - see here

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:25):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:25):

iximeow created PR Review Comment:

(I've reverted 29c6c40 and the assertion this comment is on is once again a meaningful)

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 22:30):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 23:56):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 14 2020 at 00:03):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 27 2020 at 17:56):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 02 2020 at 19:04):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 02 2020 at 20:02):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2020 at 17:04):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 18:22):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 18:22):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 18:22):

peterhuene created PR Review Comment:

Can we create a new issue to track the stack layout for CSRs problem and link here instead of the PR? My concern is only that it's hard to make out what's relevant of a complex PR like this one.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 18:22):

peterhuene created PR Review Comment:

Given users might run into this panic on Windows until we fix the underlying issue (granted, without the panic they weren't getting proper register restores or unwind which is a more severe problem), perhaps we should note that this is a known limitation and link to the GitHub issue describing the problem?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 19:51):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 19:51):

iximeow created PR Review Comment:

Absolutely. That's the third item in my to-do list which I've been waiting for even a preliminary :heavy_check_mark: to actually file.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 19:52):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 19:52):

iximeow created PR Review Comment:

This is a good idea. I'll add that in once I have an issue filed.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 06 2020 at 23:44):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

nit: can you expand the date as February 2nd, 2020, please? I read this as "May 2nd", as a European person :)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

Uh? Do we prefix Vec::new() this way in other places in this file?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

light suggestion: a cheaper alternative which avoids a check below:

if let Some(fpr_slot) = fpr_slot {
debug_assert!(csrs.iter(FPR).len() != 0);

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

(Reopening) Can you add a comment in the code expliciting your conclusion for choosing ExplicitSlot, please?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

Can you copy the comment telling that R11 can be clobbered in any convention?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

We have a codegen error for implementation limits. Can we return a Result from this function, and return the impl limit reached error in this case, instead of panicking?

(Otherwise, this blocks fuzzing, among other things.)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

Same possibility to do if let Some(fpr_slot) = fpr_slot { here.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 08:19):

bnjbvr created PR Review Comment:

nit: can you move this definition just before its first use, above the for loop at line 904?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 09:30):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 09:30):

iximeow created PR Review Comment:

Oops, yeah I should expand that :)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 09:47):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 09:47):

iximeow created PR Review Comment:

I'm curious for @peterhuene's thoughts on this, because #1466 will hopefully land relatively quickly after this does. Does #1466 PR introduce a reason for unwind information to be fallible?

If this is the only reason for an occasional failure, we could make this Result with the understanding that when it stops being Result we can revert this back to a non-Result function. I'm not sure that there's a reason this should be fallible, generally speaking. I only prefer a panic because I see this as something that _should_ be an important issue to resolve promptly, but I realize that might not be very nice to downstream users (including us fuzzing :) ).

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:02):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:02):

iximeow created PR Review Comment:

we in fact do not! The fully-qualified Vec reads a bit odd to me too, but I figured we can hoist the use if the number of Vec-referrers goes up to two.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:03):

iximeow edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:06):

bjorn3 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:06):

bjorn3 created PR Review Comment:

Or use 2020-02-05. (ISO 8601

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 10:06):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 07 2020 at 11:02):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:26):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:26):

peterhuene created PR Review Comment:

Sorry, I missed this notification yesterday. I think making it Result is a good idea even if this particular platform's implementation will hopefully be infallible once this restriction is lifted. Other unwind information implementations might be fallible and it can't hurt to have some signature consistency between the functions that create the unwind info.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:29):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:29):

peterhuene created PR Review Comment:

Plenty of codgen modules have use alloc::vec::Vec, though, so I wouldn't mind this being lifted to a use.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:30):

peterhuene edited PR Review Comment.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:33):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:33):

peterhuene created PR Review Comment:

Just a reminder to update this to https://github.com/bytecodealliance/wasmtime/issues/1475.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:35):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 08 2020 at 18:35):

peterhuene created PR Review Comment:

@bnjbvr is the new comment sufficient?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 09:23):

bnjbvr submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 09:23):

bnjbvr created PR Review Comment:

Yes, looks good, thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 19:54):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 20:25):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 20:34):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 21:06):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 21:18):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 21:18):

iximeow created PR Review Comment:

I've made functions for unwind emission all Result-y. ImplLimitExceeded doesn't describe _which_ limit was exceeded, but I figure for the cases in Windows unwind info it would be very helpful to get some kind of hint, so I moved the panic message into a log::warn as well.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 21:19):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 09 2020 at 23:12):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 16:57):

bjorn3 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 16:57):

bjorn3 created PR Review Comment:

        // No-op by default
        Ok(())

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 17:02):

iximeow created PR Review Comment:

oh goodness. thanks :(

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 17:02):

iximeow submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 17:02):

iximeow updated PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 18:15):

peterhuene submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 20:27):

iximeow merged PR #1216.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 10 2020 at 20:57):

iximeow edited PR #1216 from windows-fprs-preservation to master:

Moved from https://github.com/bytecodealliance/cranelift/pull/1378.

There were a few unresolved conversations from the original PR that I'll copy below.

Last updated: Nov 22 2024 at 17:03 UTC