On Dec 21 15:20, Dave Korn wrote: > On 21/12/2011 09:42, Corinna Vinschen wrote: > > > But OTOH I have to admit that I don't see how this alignment business > > worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't > > guarantee that the stack is still 16 byte aligned in main(). If that > > worked so far, it seems like a miracle. The call stack looks like this: > > > > mainCRTStartup > > -> cygwin_crt0 > > -> _dll_crt0 > > -> _main_tls->call > > -> _main_tls->call2 > > -> dll_crt0_1 > > -> main > > > > Every function on the stack changes the stack pointer. How did that > > work? Coincidence? > > > > And then again, isn't it gcc's job to make sure that the generated code > > makes sure the stack is correctly aligned for certain opcodes? > > > > What am I missing? > > GCC assumes that the stack starts off 16-aligned when the OS hands over to > the exe's entrypoint, and then makes sure it stays that way by always rounding > stack frame sizes up to the nearest multiple of 16. Or at any rate that's how > it's supposed to work.
Ok. Does that mean my patch from http://cygwin.com/ml/cygwin/2011-12/msg00435.html should be the right thing to do for pthreads? I guess I will have to do the same in _dll_crt0 then... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple