wasm2c EH: Move away from alloca

[SoniEx2]

Move away from alloca.

EHv4 exnrefs can be stored in locals and globals and passed around, alloca isn't particularly compatible with this. While this change doesn't introduce exnref, it paves the way for doing so.

Split from #2470

[SoniEx2]

@sbc100 this is a bit overdue, @keithw actually pushed us to fix this.

[sbc100]

Can we perhaps assert this statically?

[SoniEx2]

the only reason we don't is that we'd prefer the ability to use different WASM_EXN_MAX_SIZE per module, until we get around to implementing GC

[sbc100]

But WASM_EXN_MAX_SIZE is not variable, its fixed in the header file in source control. I don't think we need to worry about variable WASM_EXN_MAX_SIZE (at least not until we have to).

How about replacing this with assert( tlabel, "_size <= WASM_EXN_MAX_SIZE)?

[SoniEx2]

if we're gonna do that, we may as well go a little extra. so, how about this?

[sbc100]

Can you explain a little more the motivation. How does this "fix the ability to catch exceptions in a loop without the runtime trapping"?

[SoniEx2]

it's a bit unintuitive, but basically:

• alloca grows the stack frame
• the space used by alloca is only released when returning
• there is no way to undo an alloca
• you can put a try inside a loop
• every time you catch, if there's a possibility of rethrowing the exception (based on presence of rethrow in any of the catch blocks), alloca is called again
• this grows forever, eventually hitting the Stack Exhaustion Handler and trapping

(ofc, that's assuming you're using the stack exhaustion handler... if you're using depth count instead, well... it'll just blow the stack.)

[sbc100]

it's a bit unintuitive, but basically:

• alloca grows the stack frame
• the space used by alloca is only released when returning
• there is no way to undo an alloca
• you can put a try inside a loop
• every time you catch, if there's a possibility of rethrowing the exception (based on presence of rethrow in any of the catch blocks), alloca is called again
• this grows forever, eventually hitting the Stack Exhaustion Handler and trapping

(ofc, that's assuming you're using the stack exhaustion handler... if you're using depth count instead, well... it'll just blow the stack.)

Is this because we are longjmp'ing back to before the alloca? Shouldn't longjump reset the stack pointer in that case to the value it had before the alloca? i.e. doesn't longjump undo alloca just fine?

[SoniEx2]

... honestly, we don't know what longjmp'ing to an alloca function does. as far as we can tell, the manpage only talks about longjmping over such a function.

[sbc100]

... honestly, we don't know what longjmp'ing to an alloca function does. as far as we can tell, the manpage only talks about longjmping over such a function.

longjump basically resets all the registers to the state they were in when setjmp was called. So if the alloca happened after the setjmp the longjmp will essentially "undo" it by simply resetting the stack pointer.

[SoniEx2]

if alloca changes the stack pointer then how does a function know where its locals are stored...?

(also, y'know, alloca is not standard C, so there's that. also, we can't use alloca with EHv4's exnrefs, which is ultimately the real reason we're doing this.)

[sbc100]

if alloca changes the stack pointer then how does a function know where its locals are stored...?

I believe the compiler uses an offset from a frame pointer in this case.

(also, y'know, alloca is not standard C, so there's that. also, we can't use alloca with EHv4's exnrefs, which is ultimately the real reason we're doing this.)

Still I'd quite like to know how exactly the alloca'd region in somehow leaked.. does it leak each up a try/catch or rethrow happens?

[SoniEx2]

we were under the assumption that longjmp wouldn't reset alloca (because that would be a massive footgun that isn't described in the man page). we suppose we can test it...

[sbc100]

if alloca changes the stack pointer then how does a function know where its locals are stored...?

I believe the compiler uses an offset from a frame pointer in this case.

Detailed info on this: https://stackoverflow.com/a/69413437/2770641

(also, y'know, alloca is not standard C, so there's that. also, we can't use alloca with EHv4's exnrefs, which is ultimately the real reason we're doing this.)

Still I'd quite like to know how exactly the alloca'd region in somehow leaked.. does it leak each up a try/catch or rethrow happens?

[sbc100]

we were under the assumption that longjmp wouldn't reset alloca (because that would be a massive footgun that isn't described in the man page). we suppose we can test it...

It seems to me that it would much more of a problem if longjmp treated dynamic and static stack allocation differently. I don't really see how it could possibly reset static stack segments but not dynamic ones since they are all interleaved in the same stack.

[SoniEx2]

this non-standard alloca thing looks increasingly worse the more we learn about it...

[SoniEx2]

... y'know what, we think we may be able to come up with a way to implement EHv4 without doing this change. we can rip it out when we implement GC.