Mail Archives: cygwin/2004/04/28/12:21:27
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/
- Raw text -