Hi! okay. In my previous email I wanted to say, "knowing M$, I'd imagine they limited it to 64k", but then thinking that stack size is determined by the linker, thought it made no sense. Now, though, the stack segment is determined by the linker, the thread stack size is probably whole different story, and it seems that it is. I actually realized that I have no idea how multiple threads share the same stack segment on any architecture/OS.
On http://msdn.microsoft.com/en-us/library/bb202727.aspx (boy, I hate navigating through MSDN), it says: "By default, a thread is created with 64 KB stack reserved. You can use this flag to increase the stack size for the new thread that was created." So, M$ limits the thread size to 64k by default, no matter what your stack segment is. And given there is little control over how the main thread is created, I'm not sure there is a way to walk around this. On Sun, Jun 7, 2009 at 3:31 AM, Danny Backx<danny.ba...@scarlet.be> wrote: > Any kind of help is welcome at this point. > > Actually I think the chkstk function used is in gcc's source code, in > the gcc/config/i386/cygwin.asm file I pointed to below. > > I've been able to tweak the values in the headers that you mention by > using ld flags : > > test2.o: test2.c > i386-mingw32ce-gcc -g -c $< > > test2.exe: test2.o > i386-mingw32ce-ld --stack 0x0100000,0x100000 \ > --heap 0x0100000,0x100000 \ > /opt/x86mingw32ce/i386-mingw32ce/lib/crt3.o \ > -g -o $@ $< \ > -L/opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0 \ > -L/opt/x86mingw32ce/i386-mingw32ce/lib \ > -lmingw32 -lgcc -lgcc_eh -lceoldname -lmingwex -lcoredll \ > /opt/x86mingw32ce/lib/gcc/i386-mingw32ce/4.4.0/crtend.o > > test2.od: test2.exe > i386-mingw32ce-objdump -x $< > $@ > > The objdump output shows that the flags are changed as they should : > SizeOfStackReserve 00100000 > SizeOfStackCommit 00100000 > SizeOfHeapReserve 00100000 > SizeOfHeapCommit 00100000 > > No joy though. > > BTW this example uses another test program than before. Relevant part of > the source : > #define STACK_SIZE 33000 > > void more(void) > { > char buf[STACK_SIZE]; > > Print("In deeper function\n"); > } > > void large(void) > { > char buf[STACK_SIZE]; > > sprintf(outbuf, "Size : %d\n", sizeof(buf)); > Print(outbuf); > memset(&buf, 0, STACK_SIZE); > Print("After memset\n"); > more(); > Print("returning\n"); > } > > The application never writes "In deeper function" and stuff that should > happen later. This means two stack allocations half the size also cause > the problem, which indicates (I think) that the linker - operating > system combination is probably to blame, not the compiler. > > Danny > > On Sun, 2009-06-07 at 01:19 +0900, Pawel Veselov wrote: >> Hi, >> >> so, umm, what help are you asking for? :) >> >> The chktsk goes down the stack and probes every page to make sure its >> accessible before it is actually overrun (I guess a costly measure to avoid >> stack overflows). I found its source code here: >> >> http://read.pudn.com/downloads63/sourcecode/embed/220997/FATFS/X86/ch >> kstk.asm__.htm >> >> So, it looks like the 66,000 is too much of a stack size. M$ says it is >> supposed to be 1MB, but I'm not sure what cegcc linker default's is. So I'd >> poke around the EXE file to see what it says for the binary stack size. >> According to pecoff_v8, there are two fields that control the stack size, >> SizeOfStackReserve, SizeOfStackCommit. >> >> Thanks, >> Pawel. >> >> 2009/6/6 Danny Backx <danny.ba...@scarlet.be> >> > >> > I've been poking in the stack limit problem that Johnny reported. >> > >> > Test program attached, it can be used with e.g. >> > i386-mingw32ce-gcc -DSTACK_SIZE=6000 -o stack6000.exe stack.c >> > i386-mingw32ce-gcc -DSTACK_SIZE=66000 -o stack66000.exe stack.c >> > >> > The stack6000 execution succeeds and leaves the expected contents in >> > out.txt : >> > In main >> > Size : 6000 >> > After memset >> > The stack66000 execution creates a dialog on the screen saying >> > Application Error >> > Application stack66000.EXE encountered a serious error and must shut >> > down >> > It also adds one line to out.txt : >> > In main >> > >> > I've built a linux gcc 4.4.0, as expected the same application has no >> > problems on linux. >> > >> > A difference between the assembly code generated for the two platforms >> > (see attached source files) is that the CE version calls a function >> > __chkstk to probe the stack (see gcc/config/i386/cygwin.asm), the linux >> > version does not. >> > >> > large: (Linux) >> > pushl %ebp >> > movl %esp, %ebp >> > subl $66024, %esp >> > movl $.LC0, %eax >> > movl $66000, 8(%esp) >> > movl %eax, 4(%esp) >> > movl $outbuf, (%esp) >> > call sprintf >> > movl $outbuf, (%esp) >> > call Print >> > >> > >> > _large: (CE) >> > pushl %ebp >> > movl %esp, %ebp >> > movl $66024, %eax >> > call ___chkstk >> > movl $66000, 8(%esp) >> > movl $LC0, 4(%esp) >> > movl $_outbuf, (%esp) >> > call _sprintf >> > movl $_outbuf, (%esp) >> > call _Print >> > >> > I've tried porting the piece of Linux assembler in the CE code. This >> > requires adding an underscore at some lines, removing dots at others. >> > The end result is the same though : crash. >> > >> > Help ! :-( >> > >> > Danny >> > -- >> > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info > -- > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info > > -- With best of best regards Pawel S. Veselov ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
