Message-ID: <4EF1F937.9040107@gmail.com>
Date: Wed, 21 Dec 2011 15:20:23 +0000
From: Dave Korn <dave.korn.cygwin@gmail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: 16 byte pthread stack alignments
References: <Pine.CYG.4.58.1112201743030.3964@PC1163-8460-XP.flightsafety.com> <20111221094211.GH23547@calimero.vinschen.de>
In-Reply-To: <20111221094211.GH23547@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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.

    cheers,
      DaveK


--
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