X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Wed, 21 Dec 2011 10:42:11 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: 16 byte pthread stack alignments
Message-ID:	<20111221094211.GH23547@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<Pine DOT CYG DOT 4 DOT 58 DOT 1112201743030 DOT 3964 AT PC1163-8460-XP DOT flightsafety DOT com>
MIME-Version:	1.0
In-Reply-To:	<Pine.CYG.4.58.1112201743030.3964@PC1163-8460-XP.flightsafety.com>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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?


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 -