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 total stack segment defaults to
1Mb? What is the purpose of modifying the stack segment size by
the linker, etc.

On Tue, Jun 9, 2009 at 2:39 PM, Danny Backx<danny.ba...@scarlet.be> wrote:
> \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 wondering where would the stack addresses be for new
>> threads.
>>
>> Thanks!
>>   Pawel.
>>
>> [pv230...@druid]~/cprog$ cat stt.c
>> #include <stdio.h>
>> #include <pthread.h>
>>
>> static void prt_stk() {
>>     int i;
>>     fprintf(stdout, "my stack is near %p\n", &i);
>> }
>>
>> static void* t_start(void * n) {
>>     prt_stk();
>>     return 0;
>> }
>>
>> int main(int argc, char ** argv) {
>>
>>     pthread_t t1;
>>     pthread_t t2;
>>     void * n;
>>     prt_stk();
>>     pthread_create(&t1, 0, t_start, 0);
>>     pthread_create(&t2, 0, t_start, 0);
>>
>>     pthread_join(t1, &n);
>>     pthread_join(t2, &n);
>>     return 0;
>>
>> }
>>
>> On Tue, Jun 9, 2009 at 3:06 AM, Danny Backx<danny.ba...@scarlet.be> wrote:
>> > 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 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 the stack
>> >> completely, it should allocate thread stacks
>> >> somewhere in that stack segment.
>> >>
>> >>
>> >> On Mon, Jun 8, 2009 at 6:06 PM, Johnny Willemsen <jwillem...@remedy.nl> 
>> >> wrote:
>> >> > 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 
>> >> > thread, use that as main thread, then we can control the stack size.
>> >> >
>> >> > I will rewrite a few tests at our side to get some objects from the 
>> >> > heap instead of from the stack.
>> >> >
>> >> > Johnny
>> >> >
>> >> >
>> >>
>> > --
>> > 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

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

Reply via email to