public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ktietz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/35124]  New: Method _alloca is defined different by MSVCRT as by gcc.
Date: Thu, 07 Feb 2008 12:34:00 -0000	[thread overview]
Message-ID: <bug-35124-15155@http.gcc.gnu.org/bugzilla/> (raw)

The method _alloca assemble implementation is written that way, that it does
not return the stack pointer. I just reserves and probes the stack space.
The MSVCRT variant declares it as a synonym for POSIX alloca().
Here are three problems by the gcc variant:
1) The stack pointer isn't returned in (eax/rax).
2) If the _alloca function is called by a value not equal to the stack
boundary,
  the stack pointer (esp/rsp) gets unaligned and OS will raise an exception for
  the next instruction pushing to the stack.
3) For target x86_64-pc-mingw32 the calling convention is treated correctly.
  For ms abi, the argument gets reserved room on stack, too. Like for the 32
  bit variant.

For the x86_64-pc-mingw32 target I attached a patch for this.
Index: gcc/gcc/config/i386/cygwin.asm
===================================================================
--- gcc.orig/gcc/config/i386/cygwin.asm
+++ gcc/gcc/config/i386/cygwin.asm
@@ -72,15 +72,44 @@ Ldone:
        pushl   %eax
        ret
 #else
-/* __alloca is a normal function call, which uses %rcx as the argument.  */
+/* __alloca is a normal function call, which uses %rcx as the argument.  And
stack space
+   for the argument is saved.  */
 __alloca:
        movq    %rcx, %rax
-       /* FALLTHRU */
+       addq    $0x7, %rax
+       andq    $0xfffffffffffffff8, %rax
+       popq    %rcx            /* pop return address */
+       popq    %r10            /* Pop the reserved stack space.  */
+       movq    %rsp, %r10      /* get sp */
+       cmpq    $0x1000, %rax   /* > 4k ?*/
+       jb      Ldone_alloca
+
+Lprobe_alloca:
+       subq    $0x1000, %r10           /* yes, move pointer down 4k*/
+       orq     $0x0, (%r10)            /* probe there */
+       subq    $0x1000, %rax           /* decrement count */
+       cmpq    $0x1000, %rax
+       ja      Lprobe_alloca                   /* and do it again */
+
+Ldone_alloca:
+       subq    %rax, %r10
+       orq     $0x0, (%r10)    /* less than 4k, just peek here */
+       movq    %r10, %rax
+       subq    $0x8, %r10      /* Reserve argument stack space.  */
+       movq    %r10, %rsp      /* decrement stack */
+
+       /* Push the return value back.  Doing this instead of just
+          jumping to %rcx preserves the cached call-return stack
+          used by most modern processors.  */
+       pushq   %rcx
+       ret

 /* ___chkstk is a *special* function call, which uses %rax as the argument.
    We avoid clobbering the 4 integer argument registers, %rcx, %rdx, 
    %r8 and %r9, which leaves us with %rax, %r10, and %r11 to use.  */
 ___chkstk:
+       addq    $0x7, %rax      /* Make sure stack is on alignment of 8.  */
+       andq    $0xfffffffffffffff8, %rax
        popq    %r11            /* pop return address */
        movq    %rsp, %r10      /* get sp */
        cmpq    $0x1000, %rax   /* > 4k ?*/


-- 
           Summary: Method _alloca is defined different by MSVCRT as by gcc.
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ktietz at gcc dot gnu dot org
 GCC build triplet: *-*-mingw32
  GCC host triplet: *-*-mingw32
GCC target triplet: *-*-mingw32


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


             reply	other threads:[~2008-02-07 12:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 12:34 ktietz at gcc dot gnu dot org [this message]
2008-02-12  2:40 ` [Bug target/35124] " nightstrike at gmail dot com
2008-02-14  1:18 ` nightstrike at gmail dot com
2008-02-14  1:20 ` pinskia at gcc dot gnu dot org
2008-02-14  1:43 ` dannysmith at users dot sourceforge dot net
2008-02-14  8:15 ` dannysmith at users dot sourceforge dot net
2008-02-14  9:01 ` ktietz at gcc dot gnu dot org
2008-02-14 17:46 ` dannysmith at users dot sourceforge dot net
2008-02-14 20:11 ` dannysmith at users dot sourceforge dot net
2009-09-01 16:20 ` ktietz at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-35124-15155@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).