Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
tbp wrote: >Building an app of mine (multithreaded) with something like -O3 -march=k8 >the binary died with an illegal instruction. The offending instruction >was a 'movaps %xmm0, 0x40(%esp)' with an unaligned esp. As that was >on a secondary thread after some external calls (opengl and so on) >i thought it had to do with some cygwin/ABI issue or something. It's an ABI incompatiblity issue, GCC expects a 16-byte aligned stack, but the Windows ABI, to the extent one actually exists, only assumes a 4-byte aligned stack (and even that's not a strict requirement). Normally it's not a problem, but if you have any callbacks in your code (eg. the one that starts the secondary thread) that are called by library functions not compiled with GCC, then the stack can get misaligned. >And 1hour ago i got g++ to produce that sequence (same app, >slightly different compilation switches like -mfpmath=sse,387): 'xorps >0x435d7c,%xmm1' That one is clearly wrong and doesn't have to do with >stack alignment. This is a GCC and/or Binutils (as/ld) bug. GCC puts constants in the ".rdata" section, but this section only 4-byte aligned. >Take note that my app doesn't generate sse1/2 on its own, it all comes >from gcc. Well, that makes the workaround simple, just use the "-mno-sse", "-mno-sse2" options, don't use the "-mfpmath=sse" option and GCC shouldn't generate any SSE1/2 instructions. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
At 04:06 a.m. 28/04/2004, Ross Ridge wrote: This is a GCC and/or Binutils (as/ld) bug. GCC puts constants in the ".rdata" section, but this section only 4-byte aligned. >Take note that my app doesn't generate sse1/2 on its own, it all comes >from gcc. Well, that makes the workaround simple, just use the "-mno-sse", "-mno-sse2" options, don't use the "-mfpmath=sse" option and GCC shouldn't generate any SSE1/2 instructions. Or, instead, add -mms-bitfields -malign-double to your CFLAGS and -Wl,--fdata-sections to your LDFLAGS sectiion. It may or may not work but at least the failure will be different. -- Alejandro López-Valencia http://dradul.tripod.com/ The limits of my language are the limits of my world. (L. Wittgenstein) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: Normally it's not a problem, but if you have any callbacks in your code (eg. the one that starts the secondary thread) that are called by library functions not compiled with GCC, then the stack can get misaligned. Every library under my control were recompiled with gcc3.4 and more specifically SDL that i used to spawn those threads. My code when it has alignement requirement tells the compiler about; the trouble is in that case that gcc emited sse instructions with 16byte requirement on its own without further checkings. GCC 3.3.1 works like a charm when using fpmath=sse on the same source, tho i haven't seen it emitting memory references in conjunction with *ps instructions. It's an ABI incompatiblity issue, GCC expects a 16-byte aligned stack, but the Windows ABI, to the extent one actually exists, only assumes a 4-byte aligned stack (and even that's not a strict requirement). Is there an official or semi official way to fix it or do i have to insert something like "mov esp, eax; and 0x15, eax; sub eax, esp" where it helps? This is a GCC and/or Binutils (as/ld) bug. GCC puts constants in the ".rdata" section, but this section only 4-byte aligned. Indeed. Alejandro López-Valencia wrote: > Or, instead, add -mms-bitfields -malign-double to your CFLAGS and > -Wl,--fdata-sections to your LDFLAGS sectiion. It may or may not work > but at least the failure will be different. I've already tried -malign-double -fdata-sections. In fact i've tried every option remotly related to alignment under sun (but -mms-bitfields that i didn't know about) to no avail. As a side note gcc 3.3.1 acts funny sometimes with -ffunction-sections -fdata-sections for cygwin/ming at link time when dealing with lots of objects. Well, that makes the workaround simple, just use the "-mno-sse", "-mno-sse2" options, don't use the "-mfpmath=sse" option and GCC shouldn't generate any SSE1/2 instructions. Or i could use gcc 3.3.1. Or use another compiler. I understand -mfpmath=sse is flagged as experimental. What i don't get is why the compiler emits totally bogus code when using default switches: -O3 -march=k8 -> boom. -O3 -march=pentium4 -> boom. I guess this has little to do with cygwin per se and i'm gonna file a bugreport to let the gcc ppl know. Thanks for your time. tbp PS: I've never found out how to build a 'cygming special' binary from gcc sources, i can only make a cygwin or mingw. What's the trick? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> -Original Message- > From: cygwin-owner On Behalf Of tbp > Sent: 28 April 2004 16:16 [ Now x-posted to gcc list, since it's seemingly a gcc issue rather than a cygwin environment issue. You might also care to refer to the current discussion on the gcc-patches mailing list under the thread "Re: [Bug target/15106] Vector varargs failure for AltiVec on ppc32 linux" which is discussing the same problem arising on ppc targets. ] > > It's an ABI incompatiblity issue, GCC expects a 16-byte > aligned stack, > > but the Windows ABI, to the extent one actually exists, only assumes > > a 4-byte aligned stack (and even that's not a strict requirement). > Is there an official or semi official way to fix it or do i have to > insert something like "mov esp, eax; and 0x15, eax; sub eax, > esp" where > it helps? I'd recommend doing that in the startup code in gcc's crt0.s myself. The real question is, is the compiler generating code that guarantees the stack stays aligned, so you can do that just once at startup? It certainly ought to. > I understand -mfpmath=sse is flagged as experimental. What i > don't get > is why the compiler emits totally bogus code when using default > switches: -O3 -march=k8 -> boom. -O3 -march=pentium4 -> boom. The division of responsibility between OS, CRT/startup and compiler leaves it unclear as to who is supposed to ensure the alignment of the stack. IMO, it's a compiler's problem to see to it that if the stack starts off aligned it remains that way, by always generating stack frames that are a multiple of the alignment requirement, and it's the CRT/startup code that is responsible for mediating between what the compiled code requires and what the underlying OS/arch provides for stack pointer alignment at startup. Of course, that's IMO, and my opinion is hardly definitive. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
At 08:51 AM 4/28/2004, Dave Korn wrote: > -Original Message- > From: cygwin-owner On Behalf Of tbp > Sent: 28 April 2004 16:16 [ Now x-posted to gcc list, since it's seemingly a gcc issue rather than a cygwin environment issue. You might also care to refer to the current discussion on the gcc-patches mailing list under the thread "Re: [Bug target/15106] Vector varargs failure for AltiVec on ppc32 linux" which is discussing the same problem arising on ppc targets. ] > > It's an ABI incompatiblity issue, GCC expects a 16-byte > aligned stack, > > but the Windows ABI, to the extent one actually exists, only assumes > > a 4-byte aligned stack (and even that's not a strict requirement). > Is there an official or semi official way to fix it or do i have to > insert something like "mov esp, eax; and 0x15, eax; sub eax, > esp" where > it helps? I'd recommend doing that in the startup code in gcc's crt0.s myself. The real question is, is the compiler generating code that guarantees the stack stays aligned, so you can do that just once at startup? It certainly ought to. > I understand -mfpmath=sse is flagged as experimental. What i > don't get > is why the compiler emits totally bogus code when using default > switches: -O3 -march=k8 -> boom. -O3 -march=pentium4 -> boom. The division of responsibility between OS, CRT/startup and compiler leaves it unclear as to who is supposed to ensure the alignment of the stack. IMO, it's a compiler's problem to see to it that if the stack starts off aligned it remains that way, by always generating stack frames that are a multiple of the alignment requirement, and it's the CRT/startup code that is responsible for mediating between what the compiled code requires and what the underlying OS/arch provides for stack pointer alignment at startup. Of course, that's IMO, and my opinion is hardly definitive. As Dave said, this is more of a gcc than a cygwin issue, provided that cygwin doesn't defeat one of the functions of binutils or gcc (as it did in the past). gcc made a decision, which is different from commercial compilers, that stack alignment requires each function to be compiled with -mpreferred-stack-alignment=4, so that it passes an aligned stack to the callee. binutils has to be built with maximum alignment set to at least 4 (as cygwin has done for some months now). stack-alignment=4 is a default for gcc, except when -Os is specified. If you use -Os, and any called function uses SSE, you must over-ride the stack alignment set by -Os. gcc did this because the stack alignment caused some applications (which don't use SSE) to fail with stack overflow. I suspect this could happen in cygwin. Because of the different division of responsibilities, if a function built by gcc is called by a function built by a commercial compiler (or by gcc -Os), the stack has a 75% probability of being mis-aligned. It may be possible to overcome this by having a wrapper function between, which is built by gcc with alignment specified, but does not use SSE. Presumably, there is a performance advantage to gcc of assuming that the caller passes an aligned stack, but not enough to persuade commercial compilers to adopt a compatible scheme. Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> -Original Message- > From: Tim Prince > Sent: 28 April 2004 17:19 > Because of the different division of responsibilities, if a > function built > by gcc is called by a function built by a commercial compiler > (or by gcc > -Os), the stack has a 75% probability of being mis-aligned. > It may be > possible to overcome this by having a wrapper function > between, which is > built by gcc with alignment specified, but does not use SSE. I once wrote a patch for gcc (for the ppc backend, but the principles should be applicable if not the actual code) to add a new -m option, the effect of which was to modify prolog generation code so that instead of just subtracting a constant from the sp to allocate the new frame, it also dynamically calculated how much extra to subtract to get the correct alignment for the resulting new sp value. It was pretty simple, involving just a few extra assembler instructions in each prolog. [ In fact, it may not be as simple as that (...any more). With the ppc eabi, the effect of allocating more space on the stack than you've actually defined in the stack frame is that a gap opens up between the outgoing args area, which grows up from the bottom of the frame, and the local vars and saved regs area, which grow down from the top of the frame. This didn't do any harm in 2.95.x, but it might well go wrong in gcc-3.x.x, where the handling of eliminable regs and starting frame offset is different. I'm also unsure about how badly this sort of malarkey might break gdb's understanding of what is going on in a function's frame, but I would imagine it would do so quite badly. ] It's a total waste of bytes in a situation where you know that the OS or CRT gets it right for you, but it would be useful in a mixed objects/abis/compilers situation. Looks like there might be call for the same sort of thing for the i.86 backend? > Presumably, there is a performance advantage to gcc of > assuming that the > caller passes an aligned stack, but not enough to persuade commercial > compilers to adopt a compatible scheme. Well, it's quicker to allocate a constant size stack frame than to dynamically calculate the alignment requirements, but only by two or three fairly trivial instructions. And although aligning the frame just once at startup and keeping it aligned by always allocating aligned-size stack frames, in some situations stack memory is a limited resource, and particularly since not all code uses vector registers, there's a lot of stack memory usage to be saved by not making all the stack frames bigger just for the sake of the very few frames for functions that actually use the vector regs. So I'd say it's probably one of those trade-offs for which there's no one 'right' answer. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, 28 Apr 2004, tbp wrote:
> Building an app of mine (multithreaded) with something like -O3
> -march=k8 the binary died with an illegal instruction. The offending
> instruction was a 'movaps %xmm0, 0x40(%esp)' with an unaligned esp.
> As that was on a secondary thread after some external calls (opengl and
> so on) i thought it had to do with some cygwin/ABI issue or something.
>
> After a day of struggling/web digging, i still had no clue.
[snip]
> I'm puzzled & surprised that nobody tripped that one earlier and i'd
> apreciate any clue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14776
I'm working with Red Hat to resolve this issue right now. The problem is
that thread stacks are not always 16 byte aligned. You could try the
following hack if you need something right away and don't mind building
your own Cygwin DLL.
2004-04-28 DJ Delorie <[EMAIL PROTECTED]>
* init.cc (threadfunc_fe): Hack to make thread stacks always 16
byte aligned.
Index: init.cc
===
RCS file: /cvs/src/src/winsup/cygwin/init.cc,v
retrieving revision 1.32
diff -u -p -r1.32 init.cc
--- init.cc 22 Mar 2004 18:30:38 - 1.32
+++ init.cc 28 Apr 2004 17:38:03 -
@@ -27,6 +27,8 @@ HANDLE sync_startup;
static void WINAPI
threadfunc_fe (VOID *arg)
{
+ (void)__builtin_return_address(1);
+ asm volatile ("andl $-16,%%esp" ::: "%esp");
_cygtls::call ((DWORD (*) (void *, void *)) (((char **)
_tlsbase)[OLDFUNC_OFFSET]), arg);
}
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, 28 Apr 2004, Tim Prince wrote: > At 08:51 AM 4/28/2004, Dave Korn wrote: > > > > From: cygwin-owner On Behalf Of tbp > > > Sent: 28 April 2004 16:16 > > > >[ Now x-posted to gcc list, since it's seemingly a gcc issue rather than a > >cygwin environment issue. It's an interoperability issue. > > I'd recommend doing that in the startup code in gcc's crt0.s myself. That won't help for threads. See: http://www.cygwin.com/ml/cygwin/2004-04/msg01134.html > > The real question is, is the compiler generating code that guarantees > > the stack stays aligned, so you can do that just once at startup? It > > certainly ought to. It is supposed to, given the call back and new thread caveats. > As Dave said, this is more of a gcc than a cygwin issue, For threads, it happens to be easiest to fix this in Cygwin. > gcc made a decision, which is different from commercial compilers, and the ABI. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, Apr 28, 2004 at 12:41:51PM -0500, Brian Ford wrote:
>On Wed, 28 Apr 2004, tbp wrote:
>
>> Building an app of mine (multithreaded) with something like -O3
>> -march=k8 the binary died with an illegal instruction. The offending
>> instruction was a 'movaps %xmm0, 0x40(%esp)' with an unaligned esp.
>> As that was on a secondary thread after some external calls (opengl and
>> so on) i thought it had to do with some cygwin/ABI issue or something.
>>
>> After a day of struggling/web digging, i still had no clue.
>[snip]
>> I'm puzzled & surprised that nobody tripped that one earlier and i'd
>> apreciate any clue.
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14776
>
>I'm working with Red Hat to resolve this issue right now. The problem is
>that thread stacks are not always 16 byte aligned. You could try the
>following hack if you need something right away and don't mind building
>your own Cygwin DLL.
This patch would only affect non-main threads. It would not affect the
main thread. Wouldn't you need to do the same thing for the main thread?
I don't understand why it would be different.
cgf
>2004-04-28 DJ Delorie <[EMAIL PROTECTED]>
>
>* init.cc (threadfunc_fe): Hack to make thread stacks always 16
> byte aligned.
>
>Index: init.cc
>===
>RCS file: /cvs/src/src/winsup/cygwin/init.cc,v
>retrieving revision 1.32
>diff -u -p -r1.32 init.cc
>--- init.cc 22 Mar 2004 18:30:38 - 1.32
>+++ init.cc 28 Apr 2004 17:38:03 -
>@@ -27,6 +27,8 @@ HANDLE sync_startup;
> static void WINAPI
> threadfunc_fe (VOID *arg)
> {
>+ (void)__builtin_return_address(1);
>+ asm volatile ("andl $-16,%%esp" ::: "%esp");
> _cygtls::call ((DWORD (*) (void *, void *)) (((char **)
>_tlsbase)[OLDFUNC_OFFSET]), arg);
> }
>
>--
>Brian Ford
>Senior Realtime Software Engineer
>VITAL - Visual Simulation Systems
>FlightSafety International
>the best safety device in any aircraft is a well-trained pilot...
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Problem reports: http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, 28 Apr 2004, Christopher Faylor wrote:
> On Wed, Apr 28, 2004 at 12:41:51PM -0500, Brian Ford wrote:
> This patch would only affect non-main threads. It would not affect the
> main thread. Wouldn't you need to do the same thing for the main thread?
> I don't understand why it would be different.
Something already does. I didn't try and track down the what/why.
00401060 <_main>:
401060: 55 push %ebp
401061: b8 10 00 00 00 mov$0x10,%eax
401066: 89 e5 mov%esp,%ebp
401068: 83 ec 08sub$0x8,%esp
40106b: 83 e4 f0and$0xfff0,%esp <-- SEE
This problem doesn't happen for the main thread. I'll try to pin the who
down if you like.
> >2004-04-28 DJ Delorie <[EMAIL PROTECTED]>
> >
> >* init.cc (threadfunc_fe): Hack to make thread stacks always 16
> > byte aligned.
> >
> >Index: init.cc
> >===
> >RCS file: /cvs/src/src/winsup/cygwin/init.cc,v
> >retrieving revision 1.32
> >diff -u -p -r1.32 init.cc
> >--- init.cc 22 Mar 2004 18:30:38 - 1.32
> >+++ init.cc 28 Apr 2004 17:38:03 -
> >@@ -27,6 +27,8 @@ HANDLE sync_startup;
> > static void WINAPI
> > threadfunc_fe (VOID *arg)
> > {
> >+ (void)__builtin_return_address(1);
> >+ asm volatile ("andl $-16,%%esp" ::: "%esp");
> > _cygtls::call ((DWORD (*) (void *, void *)) (((char **)
> >_tlsbase)[OLDFUNC_OFFSET]), arg);
> > }
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, Apr 28, 2004 at 02:30:47PM -0500, Brian Ford wrote:
>On Wed, 28 Apr 2004, Christopher Faylor wrote:
>
>> On Wed, Apr 28, 2004 at 12:41:51PM -0500, Brian Ford wrote:
>> This patch would only affect non-main threads. It would not affect the
>> main thread. Wouldn't you need to do the same thing for the main thread?
>> I don't understand why it would be different.
>
>Something already does. I didn't try and track down the what/why.
>
>00401060 <_main>:
> 401060: 55 push %ebp
> 401061: b8 10 00 00 00 mov$0x10,%eax
> 401066: 89 e5 mov%esp,%ebp
> 401068: 83 ec 08sub$0x8,%esp
> 40106b: 83 e4 f0and$0xfff0,%esp <-- SEE
>
>This problem doesn't happen for the main thread. I'll try to pin the who
>down if you like.
Nope. It must be happening in crt0.c.
This patch looks reasonable (although I wonder at the need for
__builtin_return_address(1)).
Interestingly enough, this wouldn't have been generically fixable prior
to Cygwin 1.5.6.
cgf
>> >2004-04-28 DJ Delorie <[EMAIL PROTECTED]>
>> >
>> >* init.cc (threadfunc_fe): Hack to make thread stacks always 16
>> >byte aligned.
>> >
>> >Index: init.cc
>> >===
>> >RCS file: /cvs/src/src/winsup/cygwin/init.cc,v
>> >retrieving revision 1.32
>> >diff -u -p -r1.32 init.cc
>> >--- init.cc 22 Mar 2004 18:30:38 - 1.32
>> >+++ init.cc 28 Apr 2004 17:38:03 -
>> >@@ -27,6 +27,8 @@ HANDLE sync_startup;
>> > static void WINAPI
>> > threadfunc_fe (VOID *arg)
>> > {
>> >+ (void)__builtin_return_address(1);
>> >+ asm volatile ("andl $-16,%%esp" ::: "%esp");
>> > _cygtls::call ((DWORD (*) (void *, void *)) (((char **)
>> >_tlsbase)[OLDFUNC_OFFSET]), arg);
>> > }
>
>--
>Brian Ford
>Senior Realtime Software Engineer
>VITAL - Visual Simulation Systems
>FlightSafety International
>the best safety device in any aircraft is a well-trained pilot...
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Problem reports: http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, 28 Apr 2004, Christopher Faylor wrote: > On Wed, Apr 28, 2004 at 02:30:47PM -0500, Brian Ford wrote: > >Something already does. I didn't try and track down the what/why. [snip probably irrelevent assembly dump] > >This problem doesn't happen for the main thread. > > Nope. It must be happening in crt0.c. Sorry, I really need to pin that down for sure. I'll do that. > This patch looks reasonable (although I wonder at the need for > __builtin_return_address(1)). (quoting DJ) He wanted to force a full call frame. The call actually gets optimized away, but the desired effect remains, hence gcc "happens" to "do the right thing" tm. This is officially on Corinna's paid Red Hat plate for us now, so don't bother spending volunteer time on it ;-). > Interestingly enough, this wouldn't have been generically fixable prior > to Cygwin 1.5.6. I know, thanks. It was very easy given your work :-). -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, 28 Apr 2004, Brian Ford wrote: > On Wed, 28 Apr 2004, Christopher Faylor wrote: > > Interestingly enough, this wouldn't have been generically fixable prior > > to Cygwin 1.5.6. > > I know, thanks. It was very easy given your work :-). Oh, and..., just for the record: it's not *totally* generically fixable. Anything called from some win32 call-back routine is still suspect. You knew that, but everyone else might not have. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
At 12:08 PM 4/28/2004, you wrote: On Wed, Apr 28, 2004 at 12:41:51PM -0500, Brian Ford wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14776 > >I'm working with Red Hat to resolve this issue right now. The problem is >that thread stacks are not always 16 byte aligned. You could try the >following hack if you need something right away and don't mind building >your own Cygwin DLL. This patch would only affect non-main threads. It would not affect the main thread. Wouldn't you need to do the same thing for the main thread? I don't understand why it would be different. cgf Unless something has changed recently, gcc has never supported alignment of local data, or code which requires it, in main(). main() aligns stack, subject to the options specified, for each function called. Certain commercial compilers have supported alignment in the past only with the use of (non-portable) declspec. Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: > Normally it's not a problem, but if you have any callbacks in your code > (eg. the one that starts the secondary thread) that are called by library > functions not compiled with GCC, then the stack can get misaligned. tbp wrote: > Every library under my control were recompiled with gcc3.4 and more > specifically SDL that i used to spawn those threads. Apparently the code that SDL calls to create the threads doesn't create threads with aligned stacks. If SDL is using Cygwin functions to create threads but these functions are creating threads that don't have 16-byte aligned stacks then this is a Cygwin problem. > > It's an ABI incompatiblity issue, GCC expects a 16-byte aligned stack, > > but the Windows ABI, to the extent one actually exists, only assumes > > a 4-byte aligned stack (and even that's not a strict requirement). > Is there an official or semi official way to fix it or do i have to > insert something like "mov esp, eax; and 0x15, eax; sub eax, esp" where > it helps? You need to write an assembler function (you can't use inline assembly to fix this problem reliably) for each callback function in your code that's called *directly* by a function that's not compile with GCC. Something like this: .global _new_thread_callback_align_stack _new_thread_callback_align_stack: pushl %ebp movl %esp,%ebp subl $4*2, %esp /* subtract total size of all args */ andl $~15, %esp /* align stack */ movl 8(%ebp),%eax /* incoming arg 1 */ movl %eax,(%esp)/* outgoing arg 1 */ movl 12(%ebp),%eax /* incoming arg 2 */ movl %eax,4(%esp) /* outgoing arg 2 */ call _new_thread_callback leave ret > PS: I've never found out how to build a 'cygming special' binary from > gcc sources, i can only make a cygwin or mingw. What's the trick? Download and compile the Cygwin modified sources. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
>> Nope. It must be happening in crt0.c. >Sorry, I really need to pin that down for sure. I'll do that. I'm not sure why it would matter, presumably Cygwin isn't compiled with any flags that would enable SSE/SSE2 instructions and so there wouldn't be any need to have a 16-byte aligned stack in between the time mainCRTStartup() is called by Windows and main() is called by Cygwin. But, I notice that on my machine that Windows just happens to call mainCRTStartup() with a 16-byte aligned stack. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Brian Ford wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14776 I wonder how i've missed that one. My bugzilla-fu is weak. I'm working with Red Hat to resolve this issue right now. The problem is that thread stacks are not always 16 byte aligned. You could try the following hack if you need something right away and don't mind building your own Cygwin DLL. Surely not, thanks a lot. That will surely do wonders for the stack alignement issue, but there's another fold that i'm still unsure how to handle. Under some circumstances some *ps instructions are generated touching non local memory (put in .rdata with 4 byte alignement as pointed out by Ross Ridge): objdump ...|grep ... 404264: xorps 0x43af84,%xmm4 4062a7: xorps 0x43b304,%xmm2 40872a: xorps 0x43b33c,%xmm2 40ab83: andps 0x43b8ec,%xmm0 40c5ab: xorps 0x43bbb0,%xmm0 41dc47: xorps 0x444358,%xmm2 42b006: xorps 0x43ad94,%xmm1 I guess i could try to track those constants and put them in their own section or something, but is there a proper fix in the work by someone knowledgeable? Thanks for your time, tbp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: Apparently the code that SDL calls to create the threads doesn't create threads with aligned stacks. If SDL is using Cygwin functions to create threads but these functions are creating threads that don't have 16-byte aligned stacks then this is a Cygwin problem. SDL is a bit of a pain regarding cygwin (they insist on using mingw etc)... Anyway with Brian Ford patch in hand i have some chances to teach it how to behave. You need to write an assembler function (you can't use inline assembly to fix this problem reliably) for each callback function in your code that's called *directly* by a function that's not compile with GCC. Something like this: Ah, i didn't know about the no-inline asm clause (my kludge didn't seem to do any good). Thanks for the clue. PS: I've never found out how to build a 'cygming special' binary from gcc sources, i can only make a cygwin or mingw. What's the trick? Download and compile the Cygwin modified sources. Doh :) Thanks for time, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> -Original Message- > From: cygwin-owner On Behalf Of tbp > Sent: 29 April 2004 06:38 > That will surely do wonders for the stack alignement issue, > but there's > another fold that i'm still unsure how to handle. Under some > circumstances some *ps instructions are generated touching non local > memory (put in .rdata with 4 byte alignement as pointed out > by Ross Ridge): > objdump ...|grep ... >404264: xorps 0x43af84,%xmm4 >4062a7: xorps 0x43b304,%xmm2 >40872a: xorps 0x43b33c,%xmm2 >40ab83: andps 0x43b8ec,%xmm0 >40c5ab: xorps 0x43bbb0,%xmm0 >41dc47: xorps 0x444358,%xmm2 >42b006: xorps 0x43ad94,%xmm1 > > I guess i could try to track those constants and put them in > their own > section or something, but is there a proper fix in the work > by someone > knowledgeable? Not a fix, but a workaround: specify them all explicitly as const vector int variables (initialised to the relevant value), then you can use the __attribute__ ((aligned (...))) syntax. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> SDL is a bit of a pain regarding cygwin (they insist on using mingw > etc)... Well, if SDL is using Win32 functions to create threads then that's something that needs to be fixed in SDL. > Under some circumstances some *ps instructions are generated touching >non local memory (put in .rdata with 4 byte alignement as pointed out >by Ross Ridge): ... >40872a: xorps 0x43b33c,%xmm2 >40ab83: andps 0x43b8ec,%xmm0 ... >I guess i could try to track those constants and put them in their own >section or something, but is there a proper fix in the work by someone >knowledgeable? Probably not, I don't think this bug has been reported yet. I modified my copy of GCC to not put constants in .rdata, and put them in .text like older versions of GCC used to do. That's not a good fix though. A better fix would be to modify binutils to so that .rdata has a hardcoded 16-byte input section alignment, just like .text and .data have currently. The proper fix would be for binutils to actually support section alignment in PE COFF object files. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: Well, if SDL is using Win32 functions to create threads then that's something that needs to be fixed in SDL. SDL on cygwin as a whole must be fixed ;) I'll see what's their take on the subject once i get a functionnal binary etc. Probably not, I don't think this bug has been reported yet. I modified my copy of GCC to not put constants in .rdata, and put them in .text like older versions of GCC used to do. That's not a good fix though. A better fix would be to modify binutils to so that .rdata has a hardcoded 16-byte input section alignment, just like .text and .data have currently. The proper fix would be for binutils to actually support section alignment in PE COFF object files. I see. It's much more reasonable. Tho i find rather strange that gcc doesn't put those in a special section and implicitely asks for a 16 bytes alignement for all constants (when it's only really needed for some specific target optimizations), but that's just my armchair expert opinion. If the burden falls onto binutils, so be it. Is that considered as a cygwin only 'issue' or a more general one, and where should i forward this discussion? (it sounds like it's time to give PE & binutils a glance) Thanks for your time, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Wed, Apr 28, 2004 at 03:22:53PM -0500, Brian Ford wrote: >On Wed, 28 Apr 2004, Brian Ford wrote: > >> On Wed, 28 Apr 2004, Christopher Faylor wrote: >> > Interestingly enough, this wouldn't have been generically fixable prior >> > to Cygwin 1.5.6. >> >> I know, thanks. It was very easy given your work :-). > >Oh, and..., just for the record: it's not *totally* generically fixable. >Anything called from some win32 call-back routine is still suspect. I kn.. >You knew that, but everyone else might not have. Oh, right. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Thu, Apr 29, 2004 at 07:02:49AM -0400, Ross Ridge wrote: >> SDL is a bit of a pain regarding cygwin (they insist on using mingw >> etc)... > >Well, if SDL is using Win32 functions to create threads then that's >something that needs to be fixed in SDL. DJ/Brian's patch would affect all thread creation, including threads created by "CreateThread". cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> I see. It's much more reasonable. Tho i find rather strange that gcc > doesn't put those in a special section and implicitely asks for a 16 > bytes alignement for all constants (when it's only really needed for > some specific target optimizations), but that's just my armchair expert > opinion. GCC does ask for 16-byte alignment for the SSE constants, but the request isn't honoured by binutils. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: GCC does ask for 16-byte alignment for the SSE constants, but the request isn't honoured by binutils. I see ... .align 16 LC2: .long 2147483647 .long 0 .long 0 .long 0 .align 4 ... andps LC2, %xmm0 ... After uselessly poking at binutil sources for a couple of hours, may i ask you to share your gcc kludge? Regards, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Christopher Faylor wrote: DJ/Brian's patch would affect all thread creation, including threads created by "CreateThread". That's what SDL uses right now. Regards, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Thu, Apr 29, 2004 at 07:46:04PM +0200, tbp wrote: >Christopher Faylor wrote: >>DJ/Brian's patch would affect all thread creation, including threads >>created by "CreateThread". >That's what SDL uses right now. The patch has only existed for a brief time and it relies on a cygwin DLL change. How could SDL be using it? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Christopher Faylor wrote: >On Thu, Apr 29, 2004 at 07:46:04PM +0200, tbp wrote: >>Christopher Faylor wrote: >>>DJ/Brian's patch would affect all thread creation, including threads >>>created by "CreateThread". >> >>That's what SDL uses right now. > >The patch has only existed for a brief time and it relies on a cygwin >DLL change. How could SDL be using it? CreateThread, I'm guessing, is the implied "it" that SDL uses right now, not DJ/Brian's patch. -Richard Campbell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Christopher Faylor wrote: The patch has only existed for a brief time and it relies on a cygwin DLL change. How could SDL be using it? I meant CreateThread is the API SDL uses under the hood to create threads on win32. http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/thread/win32/SDL_systhread.c?rev=1.5&content-type=text/x-cvsweb-markup -- Regards, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Thu, Apr 29, 2004 at 08:00:56PM +0200, tbp wrote: >Christopher Faylor wrote: >>The patch has only existed for a brief time and it relies on a cygwin >>DLL change. How could SDL be using it? >I meant CreateThread is the API SDL uses under the hood to create >threads on win32. > >http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/thread/win32/SDL_systhread.c?rev=1.5&content-type=text/x-cvsweb-markup Ok. I mentioned that the patch would work with CreateThread so this is a non-issue. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> After uselessly poking at binutil sources for a couple of hours, may i > ask you to share your gcc kludge? Try reversing this patch: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/cygming.h.diff?cvsroot=gcc&r1=1.7&r2=1.8 Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db // -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
Ross Ridge wrote: Try reversing this patch: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/cygming.h.diff?cvsroot=gcc&r1=1.7&r2=1.8 Patched gcc 3.4 + patched cygwin1.dll = success. Thanks a lot. So, i have to ask 2 annoying questions: a) is Brian Ford patch to threadfunc_fe gonna make it to the official cygwin at some point in one form or another? b) what can be done about the gcc/binutil thing? Should i raise the issue with the binutils and/or gcc ppl or just sit on it? PS: Excuse my ignorance, but is there a way to keep a local copy of cygwin1.dll without getting caught by the cygwin-system-consistency police? -- Regards, tbp. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.0 cygwin, codegen SSE & alignement issues
On Apr 30 13:59, tbp wrote: > Ross Ridge wrote: > >Try reversing this patch: > > > > > > http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/cygming.h.diff?cvsroot=gcc&r1=1.7&r2=1.8 > Patched gcc 3.4 + patched cygwin1.dll = success. Thanks a lot. > > So, i have to ask 2 annoying questions: > a) is Brian Ford patch to threadfunc_fe gonna make it to the official > cygwin at some point in one form or another? I've just applied it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues
> -Original Message- > From: cygwin-owner On Behalf Of tbp > Sent: 30 April 2004 12:59 > PS: Excuse my ignorance, but is there a way to keep a local copy of > cygwin1.dll without getting caught by the > cygwin-system-consistency police? Yep, just make sure it's stashed away safely in a directory that isn't in your $PATH setting. Don't cd into that directory and then try and execute any cygwin programs either. Or just rename it to something other than cygwin1.dll. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
