public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc.
@ 2008-02-07 12:34 ktietz at gcc dot gnu dot org
2008-02-12 2:40 ` [Bug target/35124] " nightstrike at gmail dot com
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-07 12:34 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
@ 2008-02-12 2:40 ` nightstrike at gmail dot com
2008-02-14 1:18 ` nightstrike at gmail dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-12 2:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from nightstrike at gmail dot com 2008-02-12 02:39 -------
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00350.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
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
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: nightstrike at gmail dot com @ 2008-02-14 1:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from nightstrike at gmail dot com 2008-02-14 01:17 -------
This bug needs to be finished off before 4.3.0 closes...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
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
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-02-14 1:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-14 01:20 -------
(In reply to comment #2)
> This bug needs to be finished off before 4.3.0 closes...
Why? it has been a bug in GCC for a while now. And x86_64-pc-mingw32 is new.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (2 preceding siblings ...)
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
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2008-02-14 1:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from dannysmith at users dot sourceforge dot net 2008-02-14 01:43 -------
Actually, I see this as unfortunate choice of name for the undocumented
__alloca label rather than as a serious bug.
__alloca is an internal symbol that should have been named _alloca_probe for
consistency with MSVCT.
Certainly it is not a regression. It has been that way since 1996. The mingw
header malloc.h does this to get a MSVCRT-consistent alloca:
#ifdef __GNUC__
#define _alloca(x) __builtin_alloca((x))
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (3 preceding siblings ...)
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
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2008-02-14 8:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from dannysmith at users dot sourceforge dot net 2008-02-14 08:14 -------
And just think of the havoc that will be caused with old mingw32 and cygwin
libs that depend on the _chkstk meaning of __alloca if you change __alloca
semantics.
eg there are 69 undefined references to __alloca in mingw32-gcc-4.2.1 built
libgmp.a
In my opinion it is a bug that 64 bit mingw defines __alloca differently to 32
bit mingw.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (4 preceding siblings ...)
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
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2008-02-14 9:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from ktietz at gcc dot gnu dot org 2008-02-14 09:00 -------
I agree, that the havoc for 32-bit backward compatibility is to avoid.
But the havoc for windows sources using -fno-builtin and using _alloca () for
stack allocation produces in future even more troubles IMHO.
We allready defined the macro _alloca as 32-bit mingw does. The next source
tarball will inherit this patch.
But if we simply add a return type in eax for 32-bit world, does this really
harm anybody?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (5 preceding siblings ...)
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
8 siblings, 0 replies; 10+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2008-02-14 17:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from dannysmith at users dot sourceforge dot net 2008-02-14 17:46 -------
(In reply to comment #6)
> I agree, that the havoc for 32-bit backward compatibility is to avoid.
> But the havoc for windows sources using -fno-builtin and using _alloca () for
> stack allocation produces in future even more troubles IMHO.
Why should windows sources need to use __alloca.
If someone really wants an MSCV compatible (one underscore) _alloca they just
add this to their srcs
void *_alloca (size_t size) {return __builtin_alloca (size));
MSDN documentation says that "This function is deprecated because a more secure
version is available; see _malloca."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (6 preceding siblings ...)
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
8 siblings, 0 replies; 10+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2008-02-14 20:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from dannysmith at users dot sourceforge dot net 2008-02-14 20:10 -------
(In reply to comment #7)
> If someone really wants an MSCV compatible (one underscore) _alloca they just
> add this to their srcs
> void *_alloca (size_t size) {return __builtin_alloca (size));
>
Ugh. Sorry, I wasn't thinking clearly. Currently, that will lead to circular
reference. I'll change gen_allocate_stack_worker to use __chkstk for 32-bits
when 4.4. opens.
Just #define _alloca __builtin_alloca, That isn't affected by -fno-builtin
anyway
Danny
>
> MSDN documentation says that "This function is deprecated because a more secure
> version is available; see _malloca."
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
` (7 preceding siblings ...)
2008-02-14 20:11 ` dannysmith at users dot sourceforge dot net
@ 2009-09-01 16:20 ` ktietz at gcc dot gnu dot org
8 siblings, 0 replies; 10+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-09-01 16:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 16:20 -------
As the initial reason of this bug is solved, I close it. In fact is the
__chkstk function here incompatible to VC version, but this should be part of a
feature request.
--
ktietz at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-09-01 16:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-07 12:34 [Bug target/35124] New: Method _alloca is defined different by MSVCRT as by gcc ktietz at gcc dot gnu dot org
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
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).