Page MenuHomePhabricator

Remove __builtin_wasm_rethrow builtin

Authored by aheejin on Sep 15 2017, 2:28 PM.



Remove __builtin_wasm_rethrow builtin. I thought it was required to implement
__cxa_rethrow function in libcxxabi, but it turned out it will be using
__builtin_wasm_throw instead.

Event Timeline

aheejin created this revision.Sep 15 2017, 2:28 PM
jgravelle-google accepted this revision.Sep 15 2017, 3:00 PM
This revision is now accepted and ready to land.Sep 15 2017, 3:00 PM
aheejin closed this revision.Sep 15 2017, 3:02 PM
dschuff edited edge metadata.Sep 15 2017, 3:06 PM

So, it just occurred to me; we don't have 2-phase unwinding, which is useful to get good stack traces for debugging (because if you have unhandled exceptions you can abort before the second phase, rather than after the stack has been unwound). If the VM has an exception object from the original throw, it should have a stack trace attached to it. If we rethrow rather than throwing anew each time, then it will be preserved. So could we try to use rethrow instead of throw where possible? If we think it even might be feasible, it might be worth leaving rethrow in for now.

It may be worth considering keeping this builtin, even if there's no immediate use for it. If someone ever does need to use this instruction, such as to implement an alternate exception-handling strategy, a builtin would mean they wouldn't have to fall back to inline asm.

Hmm. I somehow thought it's not possible to implement __cxa_rethrow using rethrow instruction, but to think about it, it might be actually possible. I guess I can't restore them within this CL and should open another one...?

@dschuff I can restore it, and maybe I should, but I don't know how it would make a difference in preserving stack traces. Even if I will change __cxa_rethrow's implementation to use rethrow, only thing that changes is VM will get the argument (thrown object) from a separate storage reserved for rethrow rather than get it from the top of Wasm value stack. __cxa_rethrow does not reallocate exception object no matter which instruction (throw or rethrow) it uses.

Right, I was actually referring to the VM's internal tracking of exception stacks. I'm assuming it will use its usual mechanism for JS exceptions, which does keep a stack trace that you can access from JS code. Rethrowing rather than a new throw might keep that one intact. It doesn't help with the C++ state, but it's still better than nothing.