<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:shravanrn@gmail.com" title="Shravan Narayan <shravanrn@gmail.com>"> <span class="fn">Shravan Narayan</span></a>
</span> changed
          <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - wasm-ld: silent linear memory corruption due to limited unsafe stack size"
   href="https://bugs.llvm.org/show_bug.cgi?id=51173">bug 51173</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>INVALID
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - wasm-ld: silent linear memory corruption due to limited unsafe stack size"
   href="https://bugs.llvm.org/show_bug.cgi?id=51173#c2">Comment # 2</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - wasm-ld: silent linear memory corruption due to limited unsafe stack size"
   href="https://bugs.llvm.org/show_bug.cgi?id=51173">bug 51173</a>
              from <span class="vcard"><a class="email" href="mailto:shravanrn@gmail.com" title="Shravan Narayan <shravanrn@gmail.com>"> <span class="fn">Shravan Narayan</span></a>
</span></b>
        <pre>Thanks for the quick response Sam! (

(In reply to Sam Clegg from <a href="show_bug.cgi?id=51173#c1">comment #1</a>)
<span class="quote">> Pretty exciting to hear you are wasm inside of FF!

> You can control the size of the stack using `-z stack-size=XXX`.</span >

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


<span class="quote">> 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).</span >

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

<span class="quote">> In terms of adding more checks, in emscripten we have the
> STACK_OVERFLOW_CHECK settings:

> <a href="https://github.com/emscripten-core/emscripten/blob/">https://github.com/emscripten-core/emscripten/blob/</a>
> 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:
> <a href="https://github.com/WebAssembly/binaryen/blob/main/src/passes/StackCheck.cpp">https://github.com/WebAssembly/binaryen/blob/main/src/passes/StackCheck.cpp</a></span >

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. )</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>