[llvm-bugs] [Bug 51173] wasm-ld: silent linear memory corruption due to limited unsafe stack size

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51173

Shravan Narayan <shravanrn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Shravan Narayan <shravanrn at gmail.com> ---
Thanks for the quick response Sam! (

(In reply to Sam Clegg from comment #1)
> Pretty exciting to hear you are wasm inside of FF!
> 
> You can control the size of the stack using `-z stack-size=XXX`.

Oh fantastic! Just tried it out and it works great! :) 


> The main reason for putting global data first is that it can result in
> slightly smaller binaries since references to global data in the code we
> produce shorter instructions (`i32.const X`) when LEB encoded (Unlike stack
> addresses which are not absolute and don't appear in the code like this).

Ah I see, that makes sense! Just thinking out loud, I wonder if the right
balance would be to use --stack-first by default, but to disable this when
compiling this with "-Os". My thinking here is that for AOT compiled use cases
(such as ours), Wasm binary size is not a factor, but I definitely recognize
that is not the case for many of Wasm's current uses

> In terms of adding more checks, in emscripten we have the
> STACK_OVERFLOW_CHECK settings:
> 
> https://github.com/emscripten-core/emscripten/blob/
> cef2313504f38d019544b1c24214b9b27b804b5e/src/settings.js#L68-L79
> 
> This in turn is powered by a binaryen pass which can be run on any wasm
> binary to annotate stack accesses:
> https://github.com/WebAssembly/binaryen/blob/main/src/passes/StackCheck.cpp

Oh cool! I'll have a closer look at binaryen's options as well. May come in
handy for other things

(Wasn't sure what status to close the bug since the size flag exists and the
layout is the way it is for a reason. I have closed the bug with invalid,
please feel free to adjust. )

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210723/4605331d/attachment-0001.html>