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: Mon, 15 Aug 2005 01:21:41 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Cygwin.dll crash, alloca and custom stack Message-ID: <20050815052141.GA20656@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <602EF4562299D711978800065BEECE9A0D2D30D5 AT cbrml50 DOT ag DOT gov DOT au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <602EF4562299D711978800065BEECE9A0D2D30D5@cbrml50.ag.gov.au> User-Agent: Mutt/1.5.8i On Mon, Aug 15, 2005 at 02:56:44PM +1000, Bitmead, Chris wrote: >>I've heard of sigstack and sigalstack but cygwin hasn't. > >Well that's a shame since sigaltstack is part of the base specification >for X/Open UNIX. If cygwin wants to become UNIX compatible it needs to >implement it. Yes, I know. Unless I implement this *crucial* bit of functionality it is possible that the space time continuum will implode. However, since it is not currently implemented, since there is no sign of an implementation on the horizon, and since it may be impossible to implement for Windows, that does present a problem for your implementation on cygwin. >>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. > >Actually, you can still access variables because variable are offset from >fp, not esp. One can't use omit-frame-pointer, but I can't expect to be >switching calling conventions when playing around with assembler. And the >reason fp isn't a problem is because function calls automatically push fp >onto the (new) stack, so it is restored on function return. Ack. You're right. I even made the point about the frame pointer and then lost it ten minutes later. However, I'm not sure you can rely on the fact that the frame pointer is being used for everything, especially if the code is near the function prologue. I suggested before that maybe you should mention what you're doing in the gcc mailing list. I'm sure that people there would tell you if what you are doing is safe. >>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. > >Quite possibly, but fiddling around with threads could well be a lot more >overhead, and possibly even less portable. Using posix threads is going to be quite a bit more portable than writing assembly language to set ESP, especially if you branch out into non-x86 platforms. I mentioned thread pools rather than thread because the thread pool technique reduces the overhead involved in setting up a thread for every function call. Using a thread pool would certainly be slower than simple function calls, though, that's a given, although if you are calling malloc for every new invocation of a function, there is overhead, there too. 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/