[M3devel] elimination of jmpbuf size from cm3 frontend?

[Jay K]

The stack pages must be touched in order.

It cannot be dynamically ordered in such a way that pages are skipped.It is much easier to have a static order than worry about getting a dynamic order correct.

That is, sure, you can do some large subtract all at once,but you must not skip around in the order the pages are touched.

You can defer the exception until the jmpbuf is touched,and you can get away without touching any, but whatever youtouch, must be in order.

The solution is simple though -- actually call _alloca.It gets it right.

Imagine this:
jmpbuf bufs[n];while (1)    switch (srand() % n)    {    case 0: TRY ...  break;    case 1: TRY ...  break;    case 2: TRY ...  break;    case 3: TRY ...  break;    }}

that wouldn't work properly w/o a bit of extra code.

On NT, if you write a function with more than a page of locals,the start of the function calls chkstk, which is another name for alloca,to be sure to touch the page(s).

Because, imagine you have a function with more than a page of locals,that the first thing it does is call another function. The pushing of thereturn address will touch the stack, but possibly skip a page.

If you just have lots of functions with less than a page of locals,the pushing of return addresses to make further calls is what touchesthe pages.

It is easy to see in the generated code.We likely have a bug here in NT/x86 *forever*.It is fixed in the C backend. :)The C compiler knows the rules, and is heavily used, where the NT/x86 backend does/is not.

 - Jay



Date: Sun, 19 Jul 2015 11:10:20 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; hendrik at topoi.pooq.com; m3devel at elegosoft.com
Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?


  
    
  
  
    

    Am 2015-07-19 um 10:56 schrieb Jay K:

    
    
      
      
        Merely subtracting the stack pointer isn't correct on all
          systems.
        At least on NT, stack pages must be touched in order
          without skipping any,
        for stack overflow exceptions to work correctly.
        There is a high water mark, so it isn't necessarily linear.
      
    
    

    Would that mind if the stack exception was generated somewhat 

    later when the jumpbuf actually becomes accessed?

    I would believe no.

    

    
      
        

        
        NEWA: alloca is considered kind of dangerous, in that
          failure
        is difficult to recognize, or not portably recognizable and
          handlable.
      
    
    

    The same stack overflow exception can be generated by any 

    procedure call so that I do not see why it should be that 

    dangerous. In the overwhelming majority of cases this should

    be handled as gracefully as an extension of the heap on NEW:

    simply map a new memory page as long as there is enough

    free virtual address space.

    

    

    
      
        

        
        If people can do the work/research/testing for recognizing
          stack exhaustion
        on a decent set of systems -- Linux, Solaris, FreeBSD,
          OpenBSD, NetBSD, NT,
        possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain
          traction in my mind.
      
    
    As we are planning a new realease I would believe that your new 

    alterations would become tested shortly.

    

    

    

    

    

    

    

    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/73fe76fe/attachment-0002.html>