It's not as simple as that.
I've changed the test program such that two threads are created, and
they "exist together" :
t1 = CreateThread(NULL, THREAD_STACK_SIZE,
&thread,
NULL,
STACK_SIZE_PARAM_IS_A_RESERVATION,
This is not particularly nice...
The addresses are over a megabyte apart.
Which most likely means that the stack addresses for the new threads
are allocated in the newly created regions.
My big question to M$ would be -- if this is the case, then why the main
thread is limited to 64k, when the tot
\network\x86> test3
Main 2001FB78
Deeper 20167B24
In my program, with two statements added in obvious places.
Danny
On Tue, 2009-06-09 at 12:24 +0900, Pawel Veselov wrote:
> I mean, something like this, but with Windows thread calls.
> (I can't run any cegcc code at the moment).
> Just
I mean, something like this, but with Windows thread calls.
(I can't run any cegcc code at the moment).
Just wondering where would the stack addresses be for new
threads.
Thanks!
Pawel.
[pv230...@druid]~/cprog$ cat stt.c
#include
#include
static void prt_stk() {
int i;
fprintf(stdout
Hi,
> Ok, I'll drop this from my todo list.
> Next priority was & is to get gdb + gdbserver to work for x86.
It seems that static already a lot works. See the link below, the run of
today was using shared.
http://download.theaceorb.nl/teststat/builds/WinCE6_CEgcc_Suse_11.1.html
The run before th
Ok, I'll drop this from my todo list.
Next priority was & is to get gdb + gdbserver to work for x86.
See below : it can do a few things but e.g. no "bt" yet.
Danny
\network\x86> gdbserver : /network/x86/fibo.exe
Yow main 1038
Yow main 1070
Yow main 1078
set_breakpoint_data
Command li
You probably mean something like the attached test. What do you want to
know about it ? I can run it on x86 and on ARM.
Danny
On Mon, 2009-06-08 at 18:16 +0900, Pawel Veselov wrote:
> Should the prologue code be rewritten to have
> a thread created before main() is called?
>
> Also, it'd
Should the prologue code be rewritten to have
a thread created before main() is called?
Also, it'd be interesting to see where are the
new thread stacks are created, I've looked
at how other OSes do that, and they just
simply create a new segment. Since m$ seem
to not give you stack segment for th
Hi,
> gcc code may user more of the stack than whatever code that msvc
> produces, thus
> dipping into the red zone more often. So far, I don't see how the 64k
> limit of the
> stack on the main thread can be avoided at all..
The only option I see (which also Danny proposed) is to create a worker
gcc code may user more of the stack than whatever code that msvc produces, thus
dipping into the red zone more often. So far, I don't see how the 64k
limit of the
stack on the main thread can be avoided at all..
On Mon, Jun 8, 2009 at 5:33 PM, Johnny Willemsen wrote:
>
> Hi,
>
> I have compiled t
Hi,
I have compiled the test program also with msvc for the ebox4300 device. It
seems msvc has the same behavior, the stack66000 fails.
It is strange why some of our tests do fail with gcc and not with msvc due to
the stack issue. Seems we can't resolve this with cegcc, it is something in
win
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 s
Setting a large stack in a new thread is possible as documented. Example
included. The STACK_SIZE_PARAM_IS_A_RESERVATION macro has just been
added to SVN.
\network\x86> test3
\network\x86> type \temp\out.txt
In main
begin thread
Size : 33000
After memset
In deeper function
returning
e
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-min
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
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 expec
16 matches
Mail list logo
