This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 16 byte pthread stack alignments
On Dec 21 10:42, Corinna Vinschen wrote:
> On Dec 20 17:45, Brian Ford wrote:
> > I'm just headed home from work right now, but I thought I would let you
> > know of a regression from 1.7.9. It appears the effect of this patch:
> >
> > http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00124.html
> >
> > is no longer working in the current snapshot. I'll try to narrow it down
> > to which change caused the regression and send in an STC tomorrow.
>
> Is that the first Cygwin process started from a 64 bit process on 64 bit
> XP or 2003? If so, see the new wow64_revert_to_original_stack function
> in wow64.cc and the wow64 code in _dll_crt0.
>
> I don't see how any other change could have this effect. But I also
> don't see how this could occur with the patch. Basically, what happens
> is this:
>
> newbase = some 64K aligned address on the stack
> _main_tls = newbase - CYGTLS_PADSIZE (== 12700)
> $ebp = $esp = _main_tls - 4
>
> So, assuming newbase == 0x10000
> ==> _main_tls == 0xce64
> ==> $ebp/$esp == 0xce60, which is certainly a 16 byte aligned value.
>
> 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?
On second thought I'm a bit puzzled that you refer to the patch which
tries to align the patch of the main thread while your subject talks
about pthreads.
If you mean the stack alignment of subsequently started pthreads, then
the culprit might be the changes I made to allow application-provided
stacks. See the CygwinCreateThread and thread_wrapper functions in
miscfuncs.cc. Does something like the below work for you? Even though
I don't see how this is supposed to work if an arg and the return
address, 8 bytes, are pushed onto the stack afterwards. In theory
the wrapper would have to subtract another 8 bytes after the alignment.
I still think gcc has to care for this alignment in the first place.
Index: miscfuncs.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/miscfuncs.cc,v
retrieving revision 1.75
diff -u -p -r1.75 miscfuncs.cc
--- miscfuncs.cc 17 Dec 2011 23:39:46 -0000 1.75
+++ miscfuncs.cc 21 Dec 2011 10:41:19 -0000
@@ -524,6 +524,7 @@ thread_wrapper (VOID *arg)
subl %[CYGTLS], %%ebx # Subtract CYGTLS_PADSIZE \n\
subl $4, %%ebx # Subtract another 4 bytes \n\
movl %%ebx, %%esp # Set esp \n\
+ andl $-16, %%esp # 16 bit align stack \n\
xorl %%ebp, %%ebp # Set ebp to 0 \n\
# Now we moved to the new stack. Save thread func address\n\
# and thread arg on new stack \n\
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