<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>The stack pages must be touched in order.</div><div><br></div><div><br></div><div>It cannot be dynamically ordered in such a way that pages are skipped.</div><div>It is much easier to have a static order than worry about getting a dynamic order correct.</div><div><br></div><div><br></div><div>That is, sure, you can do some large subtract all at once,</div><div>but you must not skip around in the order the pages are touched.</div><div><br></div><div><br></div><div>You can defer the exception until the jmpbuf is touched,</div><div>and you can get away without touching any, but whatever you</div><div>touch, must be in order.</div><div><br></div><div><br></div><div>The solution is simple though -- actually call _alloca.</div><div>It gets it right.</div><div><br></div><div><br></div><div>Imagine this:</div><div><br></div><div>jmpbuf bufs[n];</div><div>while (1)</div><div>    switch (srand() % n)</div><div>    {</div><div>    case 0: TRY ...  break;</div><div>    case 1: TRY ...  break;</div><div>    case 2: TRY ...  break;</div><div>    case 3: TRY ...  break;</div><div>    }</div><div>}</div><div><br></div><div><br></div><div>that wouldn't work properly w/o a bit of extra code.</div><div><br></div><div><br></div><div>On NT, if you write a function with more than a page of locals,</div><div>the start of the function calls chkstk, which is another name for alloca,</div><div>to be sure to touch the page(s).</div><div><br></div><div><br></div><div>Because, imagine you have a function with more than a page of locals,</div><div>that the first thing it does is call another function. The pushing of the</div><div>return address will touch the stack, but possibly skip a page.</div><div><br></div><div><br></div><div>If you just have lots of functions with less than a page of locals,</div><div>the pushing of return addresses to make further calls is what touches</div><div>the pages.</div><div><br></div><div><br></div><div>It is easy to see in the generated code.</div><div>We likely have a bug here in NT/x86 *forever*.</div><div>It is fixed in the C backend. :)</div><div>The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.</div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div><hr id="stopSpelling">Date: Sun, 19 Jul 2015 11:10:20 +0200<br>From: estellnb@elstel.org<br>To: jay.krell@cornell.edu; hendrik@topoi.pooq.com; m3devel@elegosoft.com<br>Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?<br><br>
  
    
  
  
    <br>
    <div class="ecxmoz-cite-prefix">Am 2015-07-19 um 10:56 schrieb Jay K:<br>
    </div>
    <blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
      <style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}

--></style>
      <div dir="ltr">
        <div>Merely subtracting the stack pointer isn't correct on all
          systems.</div>
        <div>At least on NT, stack pages must be touched in order
          without skipping any,</div>
        <div>for stack overflow exceptions to work correctly.</div>
        <div>There is a high water mark, so it isn't necessarily linear.</div>
      </div>
    </blockquote>
    <br>
    Would that mind if the stack exception was generated somewhat <br>
    later when the jumpbuf actually becomes accessed?<br>
    I would believe no.<br>
    <br>
    <blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
      <div dir="ltr">
        <div><br>
        </div>
        <div>NEWA: alloca is considered kind of dangerous, in that
          failure</div>
        <div>is difficult to recognize, or not portably recognizable and
          handlable.</div>
      </div>
    </blockquote>
    <br>
    The same stack overflow exception can be generated by any <br>
    procedure call so that I do not see why it should be that <br>
    dangerous. In the overwhelming majority of cases this should<br>
    be handled as gracefully as an extension of the heap on NEW:<br>
    simply map a new memory page as long as there is enough<br>
    free virtual address space.<br>
    <br>
    <br>
    <blockquote cite="mid:COL130-W32C4709A9C9DBF9CCB035AE6860@phx.gbl">
      <div dir="ltr">
        <div><br>
        </div>
        <div>If people can do the work/research/testing for recognizing
          stack exhaustion</div>
        <div>on a decent set of systems -- Linux, Solaris, FreeBSD,
          OpenBSD, NetBSD, NT,</div>
        <div>possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
          traction in my mind.</div>
      </div>
    </blockquote>
    As we are planning a new realease I would believe that your new <br>
    alterations would become tested shortly.<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br></div>                                        </div></body>
</html>