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 -- 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
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
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
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...#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;
}
--
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
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
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
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
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 - 1.372
+++ sigproc.cc 22 Dec 2011 15:30:58 -
@@ -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
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 VersionStatus gcc4 4.5.3-3OK 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
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.cc10 Dec 2011 01:33:56 - 1.372
+++ sigproc.cc22 Dec 2011 15:30:58 -
@@ -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
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 VersionStatus gcc4 4.5.3-3OK $ cygcheck -c gcc4 Cygwin Package Information Package VersionStatus 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
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
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 == 0x1 == _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
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 == 0x1 == _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.cc17 Dec 2011 23:39:46 - 1.75 +++ miscfuncs.cc21 Dec 2011 10:41:19 - @@ -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
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
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
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
Re: 16 byte pthread stack alignments
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
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
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
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
