[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Stack problems with GCC 4



With GCC 4 any zero initialised data ends up in the BSS section.

With our stack size we don't want that to happen and traditionally with
GCC 2.x it's ended up in the data section which is what we want.

Attached is a patch which defines _stksiz to be MINKEEP which is what
the zero initialisation means. This ensures that it ends up in the data
section correctly.

There's a compiler option in GCC 4 too called
-fno-zero-initialized-in-bss which allows stksiz.c to be compiled
without any patch and correctly puts _stksiz into the data section, but
then GCC 2.x can't compile the code because it doesn't understand the
flag.

So I opted for the patch rather than some crufty code to find out the
GCC version in the Makefile.

Alan.
Index: mintlib/stksiz.c
===================================================================
RCS file: /mint/mintlib/mintlib/stksiz.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 stksiz.c
--- mintlib/stksiz.c	12 Oct 2000 10:56:42 -0000	1.1.1.1
+++ mintlib/stksiz.c	24 Dec 2007 00:36:20 -0000
@@ -1 +1,20 @@
-long _stksize = 0L;	/* "0" means keep minimum amount: see crtinit.c */
+#define MINKEEP (24L * 1024L)		/* keep at least this much mem */
+
+/* With GCC 4, zero initialised data ends up in the BSS. We don't want
+ * that to happen for _stksiz so we declare it to MINKEEP which is what
+ * 0L really is.
+ *
+ * was 
+ *
+ * long _stksize = 0L; 
+ *
+ * see crtinit.c for _stksize definitions and duplicate MINKEEP definition.
+ *
+ * I actually like this better too, as I can see how much stack really is
+ * being defined by mintlib.
+ *
+ * Alternatively, compile this with the -fno-zero-initialized-in-bss in
+ * GCC 4 and set it back to the way it was, but that will stop GCC 2.x
+ * compiling this code.
+ */
+long _stksize = MINKEEP;