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: 16 byte pthread stack alignments

On Dec 27 18:06, Brian Ford wrote:
> On Fri, 23 Dec 2011, Corinna Vinschen wrote:
> > On Dec 22 12:51, Brian Ford wrote:
> > > On Wed, 21 Dec 2011, Corinna Vinschen wrote:
> > >
> > > > 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?!?
> > >
> > > It appears it is, here.
> > >
> > > > Does anybody care to tell me what's wrong with the assembler code in
> > > > thread_wrapper?
> > >
> > > I don't pretend to understand why, but it appears gcc is expecting the
> > > stack to be 16 byte aligned on entry to the called function, which
> > > includes the 4 byte argument and the 4 byte return address in this case.
> > > I could be wrong, but it appears that would do it.
> After studying this more today, I was wrong in my description of the cause
> and fix above.  It appears the stack needs to be 16 byte aligned at the
> call instruction.  That is, before the return address is pushed.
> > Sorry, but what I don't get from your reply is if the andl worked or
> > not.
> No; by itself, it does not.  Adding a "subl $12, %%esp" following it so
> that the stack is 16 byte aligned after the thread arg is pushed does
> work.  There are probably more efficient and/or cleaner ways of doing it
> though.
> STC attached, but note that it seems to always pass with gcc-4.  Only gcc
> 3.4.4 appears to require the extra alignment.

Ok, this is even more puzzeling.  The thread function called from the
thread_wrapper function is NOT the application thread function, but
the Cygwin internal function thread_init_wrapper.  Given that this
function is built with the same gcc 4.x compiler as the rest of Cygwin,
how on earth can this fail at all?  Shouldn't the alignment be always
correct on the subsequent call to the application function, given that
gcc-4 is supposed to care?

Dave, can you explain this?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

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