\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
Hello.
I was trying to setup rshd on my device (WM6) and i'm getting this error:
"Error creating pipe. Copy PipeDev.dll to the device.".
I couldn't find any instructions on installing rshd/PipeDev, so i'm asking
here )
I've copied this files to my device:
mingwm10.dll -> /windows
rshd.exe -> /
tes
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
10 matches
Mail list logo
