Mail Archives: cygwin/2011/12/21/11:51:49
On Dec 21 10:22, Brian Ford wrote:
> On Wed, 21 Dec 2011, Corinna Vinschen wrote:
>
> > On Dec 21 15:20, Dave Korn wrote:
> > > 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...
>
> Probably. I'm trying to test now, but I haven't built cygwin in years now
> so I'm still working to get things set up. I've also lost track of Cygwin
> internals. Does it make sense to you that those two patches from 2004
> would no longer be effective?
Cygwin now sets up the stack by itself in both cases, WOW64 startup and
pthread_create. I just made a test which showed pretty clearly that
the 16 byte alignment is required for the WOW64 case. But that case
wasn't affected because it was already correctly aligned.
On second thought I'm a bit puzzled that the pthread stack isn't
correctly aligned as well. Ignoring the pthread_attr_setstack case
which wasn't supported so far anyway, the OS stack set up by
CreateThread is 64K aligned. From that 64K aligned StackBase value, I
subtract 12704 == 0x31a0 bytes. So the result should be 16 byte
aligned even without the andl $-16, %%esp. Why isn't it?!?
Does anybody care to tell me what's wrong with the assembler code in
thread_wrapper?
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
- Raw text -