16 byte pthread stack alignments

16 byte pthread stack alignments

[Brian Ford]

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

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

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

Re: 16 byte pthread stack alignments

[Dave Korn]

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

On Dec 21 15:20, Dave Korn wrote:
> 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.

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


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

Re: 16 byte pthread stack alignments

[Brian Ford]

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?

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

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

Re: 16 byte pthread stack alignments

[Brian Ford]

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.

For a long discussion by those who apparently agree with you about how
crazy this is see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

It looks like gcc 4.6 may finally "do the right thing" itself.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

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.

Sorry, but what I don't get from your reply is if the andl worked or
not.  Is the alignment correct now or do I have to move the stack down
by another 8 bytes to account for the argument and the stack address?


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

Re: 16 byte pthread stack alignments

[Brian Ford]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

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.

PS. Note that with my custom built cygwin DLL from CVS today, I can't
compile the STC:

gcc -g -O2 -Wall pthread_sse_align.c -o pthread_sse_align.exe
pthread_sse_align.c:0: fatal error: can't open /tmp/ccMkTl4f.s for
writing: No such file or directory compilation terminated.

Also, every error message from an abnormally exiting application
(including when the attached test case fails) mysteriously seems to print
4-6 times?

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

[-- Attachment #2: Type: text/plain, Size: 972 bytes --]

#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define ALIGN16(a) a __attribute__((aligned (16)))

void *run_test(void *arg)
{
    ALIGN16(char t[16]);

    if ((long)&t[0] & 15)
    {
	fprintf(stderr, "pthread 16 byte stack variable alignment failed: t %p\n", &t[0]);
	exit(-1);
    }

    return NULL;
}

int main(int argc, char *argv[])
{
    ALIGN16(char m[16]);
    int       stat;
    pthread_t tid;

    if ((long)&m[0] & 15)
    {
	fprintf(stderr, "main thread 16 byte stack variable alignment failed: m %p\n", &m[0]);
	return -1;
    }

    stat = pthread_create(&tid, NULL, &run_test, NULL);
    if (stat)
    {
	fprintf(stderr, "pthread_create failed: %s\n", strerror(stat));
	return -1;
    }

    stat = pthread_join(tid, NULL);
    if (stat)
    {
	fprintf(stderr, "pthread_join failed: %s\n", strerror(stat));
	return -1;
    }

    printf("Test passed\n");
    return 0;
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

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


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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Mon, 9 Jan 2012, Corinna Vinschen wrote:

> On Dec 27 18:06, Brian Ford wrote:
> > On Fri, 23 Dec 2011, Corinna Vinschen wrote:
> >
> > > 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?

I'm speculating, but I believe gcc-4 only re-aligns the stack in case an
instruction in that function requires more strict alignment than the
default ABI to save overhead.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

On Jan  9 09:41, Brian Ford wrote:
> On Mon, 9 Jan 2012, Corinna Vinschen wrote:
> 
> > On Dec 27 18:06, Brian Ford wrote:
> > > On Fri, 23 Dec 2011, Corinna Vinschen wrote:
> > >
> > > > 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?
> 
> I'm speculating, but I believe gcc-4 only re-aligns the stack in case an
> instruction in that function requires more strict alignment than the
> default ABI to save overhead.

Maybe.  I applied that patch which also makes gcc 3 happy.


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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Wed, 21 Dec 2011, Brian Ford wrote:

> I'm trying to test now, but I haven't built cygwin in years so I'm still
> working to get things set up.

Still trying, but getting the following warning turned into an error by
-Werror which looks like it might be valid?

cc1plus: warnings being treated as errors
src/winsup/cygwin/fhandler.cc:
In member function fhandler_base_overlapped::wait_return
fhandler_base_overlapped::wait_overlapped(bool, bool, DWORD*, bool,
DWORD):
src/winsup/cygwin/fhandler.cc:1912:
error: err may be used uninitialized in this function

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Wed, 21 Dec 2011, Brian Ford wrote:

> Still trying, but getting the following warning turned into an error by
> -Werror which looks like it might be valid?
>
> cc1plus: warnings being treated as errors
> src/winsup/cygwin/fhandler.cc:
> In member function fhandler_base_overlapped::wait_return
> fhandler_base_overlapped::wait_overlapped(bool, bool, DWORD*, bool,
> DWORD):
> src/winsup/cygwin/fhandler.cc:1912:
> error: err may be used uninitialized in this function

Thanks for the fix Christopher, but I must be using the wrong compiler or
something.  Here's my next issue:

src/winsup/cygwin/child_info.h:
In static member function static cygheap_exec_info*
cygheap_exec_info::alloc():
src/winsup/cygwin/child_info.h:115:
error: invalid use of member cygheap_exec_info::children in static member
function
src/winsup/cygwin/sigproc.cc:914:
error: from this location

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

On Dec 21 15:25, Brian Ford wrote:
> On Wed, 21 Dec 2011, Brian Ford wrote:
> 
> > Still trying, but getting the following warning turned into an error by
> > -Werror which looks like it might be valid?
> >
> > cc1plus: warnings being treated as errors
> > src/winsup/cygwin/fhandler.cc:
> > In member function fhandler_base_overlapped::wait_return
> > fhandler_base_overlapped::wait_overlapped(bool, bool, DWORD*, bool,
> > DWORD):
> > src/winsup/cygwin/fhandler.cc:1912:
> > error: err may be used uninitialized in this function
> 
> Thanks for the fix Christopher, but I must be using the wrong compiler or
> something.  Here's my next issue:
> 
> src/winsup/cygwin/child_info.h:
> In static member function static cygheap_exec_info*
> cygheap_exec_info::alloc():
> src/winsup/cygwin/child_info.h:115:
> error: invalid use of member cygheap_exec_info::children in static member
> function
> src/winsup/cygwin/sigproc.cc:914:
> error: from this location

Did you try to drop the -Werror from the command line, for testing sake?


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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Thu, 22 Dec 2011, Corinna Vinschen wrote:

> On Dec 21 15:25, Brian Ford wrote:
> > On Wed, 21 Dec 2011, Brian Ford wrote:
> >
> > Thanks for the fix Christopher, but I must be using the wrong compiler or
> > something.  Here's my next issue:
> >
> > src/winsup/cygwin/child_info.h:
> > In static member function static cygheap_exec_info*
> > cygheap_exec_info::alloc():
> > src/winsup/cygwin/child_info.h:115:
> > error: invalid use of member cygheap_exec_info::children in static member
> > function
> > src/winsup/cygwin/sigproc.cc:914:
> > error: from this location
>
> Did you try to drop the -Werror from the command line, for testing sake?

No, because in this case it actually is an error, not one converted from a
warning.  Am I missing something, or shouldn't the cygwin sources compile
without this kind of difficulty?  Is this really just a difference between
the Cygwin gcc-4 and the one you guys use to cross compile?

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

On Dec 22 09:20, Brian Ford wrote:
> On Thu, 22 Dec 2011, Corinna Vinschen wrote:
> 
> > On Dec 21 15:25, Brian Ford wrote:
> > > On Wed, 21 Dec 2011, Brian Ford wrote:
> > >
> > > Thanks for the fix Christopher, but I must be using the wrong compiler or
> > > something.  Here's my next issue:
> > >
> > > src/winsup/cygwin/child_info.h:
> > > In static member function static cygheap_exec_info*
> > > cygheap_exec_info::alloc():
> > > src/winsup/cygwin/child_info.h:115:
> > > error: invalid use of member cygheap_exec_info::children in static member
> > > function
> > > src/winsup/cygwin/sigproc.cc:914:
> > > error: from this location
> >
> > Did you try to drop the -Werror from the command line, for testing sake?
> 
> No, because in this case it actually is an error, not one converted from a
> warning.  Am I missing something, or shouldn't the cygwin sources compile
> without this kind of difficulty?  Is this really just a difference between
> the Cygwin gcc-4 and the one you guys use to cross compile?

Should be basically the same compiler:

  i686-pc-cygwin-gcc (GCC) 4.5.3 20110428 (Fedora Cygwin 4.5.3-4)

The error message is kind of nonsense anyway.  The expression in question
is

  sizeof (cygheap_exec_info) + (nprocs * sizeof (children[0]))

so it's just a `sizeof', not an actual usage of the member.  Try this
for now:

Index: sigproc.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/sigproc.cc,v
retrieving revision 1.372
diff -u -p -r1.372 sigproc.cc
--- sigproc.cc	10 Dec 2011 01:33:56 -0000	1.372
+++ sigproc.cc	22 Dec 2011 15:30:58 -0000
@@ -911,7 +911,7 @@ cygheap_exec_info::alloc ()
 {
  return (cygheap_exec_info *) ccalloc_abort (HEAP_1_EXEC, 1,
 					     sizeof (cygheap_exec_info)
-					     + (nprocs * sizeof (children[0])));
+					     + (nprocs * sizeof (cchildren)));
 }
 
 void


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

Re: 16 byte pthread stack alignments

[Corinna Vinschen]

On Dec 22 16:31, Corinna Vinschen wrote:
> On Dec 22 09:20, Brian Ford wrote:
> > On Thu, 22 Dec 2011, Corinna Vinschen wrote:
> > 
> > > On Dec 21 15:25, Brian Ford wrote:
> > > > On Wed, 21 Dec 2011, Brian Ford wrote:
> > > >
> > > > Thanks for the fix Christopher, but I must be using the wrong compiler or
> > > > something.  Here's my next issue:
> > > >
> > > > src/winsup/cygwin/child_info.h:
> > > > In static member function static cygheap_exec_info*
> > > > cygheap_exec_info::alloc():
> > > > src/winsup/cygwin/child_info.h:115:
> > > > error: invalid use of member cygheap_exec_info::children in static member
> > > > function
> > > > src/winsup/cygwin/sigproc.cc:914:
> > > > error: from this location
> > >
> > > Did you try to drop the -Werror from the command line, for testing sake?
> > 
> > No, because in this case it actually is an error, not one converted from a
> > warning.  Am I missing something, or shouldn't the cygwin sources compile
> > without this kind of difficulty?  Is this really just a difference between
> > the Cygwin gcc-4 and the one you guys use to cross compile?
> 
> Should be basically the same compiler:
> 
>   i686-pc-cygwin-gcc (GCC) 4.5.3 20110428 (Fedora Cygwin 4.5.3-4)
> 
> The error message is kind of nonsense anyway.  The expression in question
> is
> 
>   sizeof (cygheap_exec_info) + (nprocs * sizeof (children[0]))
> 
> so it's just a `sizeof', not an actual usage of the member.  Try this
> for now:

Btw., you are apparently not running the latest gcc-4.  I just tried to
compile this file (without my patch) on Cygwin and it works fine without
any warning or error:

  $ gcc --version
  gcc (GCC) 4.5.3
  $ cygcheck -c gcc4
  Cygwin Package Information
  Package              Version        Status
  gcc4                 4.5.3-3        OK


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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Thu, 22 Dec 2011, Corinna Vinschen wrote:

> Btw., you are apparently not running the latest gcc-4.  I just tried to
> compile this file (without my patch) on Cygwin and it works fine without
> any warning or error:
>
>   $ gcc --version
>   gcc (GCC) 4.5.3

You are correct, although I just ran setup yesterday and it said I was up
to date.

$ gcc-4 --version
gcc-4 (GCC) 4.3.4 20090804 (release) 1

>   $ cygcheck -c gcc4
>   Cygwin Package Information
>   Package              Version        Status
>   gcc4                 4.5.3-3        OK

$ cygcheck -c gcc4
Cygwin Package Information
Package              Version        Status

Evidently, setup somehow lost track that I had gcc-4 installed (confused).

Thank you for your patience.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Brian Ford]

On Thu, 22 Dec 2011, Corinna Vinschen wrote:

> The error message is kind of nonsense anyway.  The expression in question
> is
>
>   sizeof (cygheap_exec_info) + (nprocs * sizeof (children[0]))
>
> so it's just a `sizeof', not an actual usage of the member.  Try this
> for now:
>
> Index: sigproc.cc
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/sigproc.cc,v
> retrieving revision 1.372
> diff -u -p -r1.372 sigproc.cc
> --- sigproc.cc	10 Dec 2011 01:33:56 -0000	1.372
> +++ sigproc.cc	22 Dec 2011 15:30:58 -0000
> @@ -911,7 +911,7 @@ cygheap_exec_info::alloc ()
>  {
>   return (cygheap_exec_info *) ccalloc_abort (HEAP_1_EXEC, 1,
>  					     sizeof (cygheap_exec_info)
> -					     + (nprocs * sizeof (children[0])));
> +					     + (nprocs * sizeof (cchildren)));
>  }

FWIW, that worked.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: 16 byte pthread stack alignments

[Brian Ford]

I'm sorry.  I should have learned by now not to post at the last minute
before leaving for the day.  I always make mistakes and leave out
important information.  Thanks for considering my problem in spite of
these oversights.  More below...

On Wed, 21 Dec 2011, 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

You were correct below that I cited the wrong patch.  I simply swiped the
wrong URL in a hurry; sorry.  This is the correct reference:

http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00108.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?

No; this is 32 bit XP Pro SP3.

Most of the rest of this has been cleared up I think, so I'll save any
further responses to later messages in the thread.  Thanks again for your
help.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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