This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin.dll crash, alloca and custom stack


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]