Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Sun, 14 Aug 2005 23:56:03 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Cygwin.dll crash, alloca and custom stack Message-ID: <20050815035603.GD18355@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <602EF4562299D711978800065BEECE9A0D2D30D4 AT cbrml50 DOT ag DOT gov DOT au> <20050815032803 DOT GB18355 AT trixie DOT casa DOT cgf DOT cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050815032803.GB18355@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.8i On Sun, Aug 14, 2005 at 11:28:04PM -0400, Christopher Faylor wrote: >On Mon, Aug 15, 2005 at 12:58:10PM +1000, Bitmead, Chris wrote: >>cgf wrote: >>>It is really not nonsensible for an OS to assume that it has control of >>>the stack. >> >>Lots of claims flying around, but no justification. An OS specified >>stack can provide automatic extension to applications that are >>interested in that feature, but apart from that I don't see why it >>should give a rip what an app does with its stack. > >The OS may care about where the stack lives and how it is laid out. >Windows allocates memory in a special way when it creates the stack to >allow automatic extension of the stack. The runtime may also care. I meant to mention that the gcc also cares about the stack pointer since when you do something like this: void * st1, *oldstack; st1 = (void *)malloc(5000) + 5000; asm("mov %%esp, %0" : "=r" (oldstack)); asm("mov %0, %%esp" : : "r" (st1)); /* stack danger here */ you can no longer access any variables in the enclosing stack frame and, given optimization, you don't always know precisely where this block of code will show up wrt the rest of the code in the function. You may be able to control this, to some extent, with the use of the volatile keyword. Maybe I don't understand precisely what you're trying to do but it seems like you could get the behavior you're looking for by setting up some thread pools and just switching to a new thread when it is time to call one of these functions which needs its own stack. On Windows you could also use fibers, rather than threads, I believe. I also have to retract what I said earlier because, on reflection, I don't see how resetting a stack pointer would matter to a multi-threaded program since the stacks are local to individual threads and, as I mentioned, Windows only cares about the memory region of the stack, not the value of the current stack pointer. So, again, the only thing you may have to worry about are cygwin signals and windows exceptions. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/