Re[2]: [Gc]: mingw32ce patch

Ivan Maidanski ivmai at mail.ru
Wed Sep 30 03:56:56 PDT 2009


Hi!

"Vincent R." <forumer at smartmobili.com> wrote:
> On Wed, 30 Sep 2009 13:55:59 +0400, Ivan Maidanski <ivmai at mail.ru> wrote:
> > Hi!
> >
> > Foreword from doc/Readme:
> >
> > "If you are contemplating a major addition, you might also send mail to
> > ask whether it's already been done (or whether we tried and discarded
> it)."
> >
> >
> ./configure --host=arm-mingw32ce
> make

I guess configure.ac needs polishing - check whether -DUSE_MUNMAP, -DTHREAD_LOCAL_ALLOC, -DPARALLEL_MARK appear in the Makefile (provided --enable-parallel-mark and friends are specified respectively).

>
> Hum from CVS seems are a lot better, I get only some errors in cord:
> cord/.libs/cordtest.o: In function `test_extras':
> /cygdrive/c/downloads/bdwgc/cord/cordtest.c:186: undefined reference to
> `remove'
> /cygdrive/c/downloads/bdwgc/cord/cordtest.c:186: relocation truncated to
> fit: ARM_26 against undefined symbol `remove'
> /cygdrive/c/downloads/bdwgc/cord/cordtest.c:190: undefined reference to
> `remove'
> /cygdrive/c/downloads/bdwgc/cord/cordtest.c:190: relocation truncated to
> fit: ARM_26 against undefined symbol `remove'
> /cygdrive/c/downloads/bdwgc/cord/cordtest.c:192: undefined reference to
> `remove'

I haven't touched cords - it's not an integral part of GC, haven't been modified by at least 2 years - IMHO, this is a historical rudiment.

> > Not fully true, AFAIK: __MINGW32CE__ is defined only for mingw32ce (not
> > for CeGCC).
> >
> Right! Didn't know I would find a cegcc expert! Actually I am not
> interested by cegcc.
> >> ...
> >
> > Everything seems to work (as report others) except may be - configure (I
> > haven't tried) - If you care send us a patch for it.
> > ...
> > There may be some problems with compiling for some WinCE 6.0 custom
> builds
> > because GCC doesn't support SEH.
> >
> Yes I know that.

Also, GCC supports -DPARALLEL_MARK only for ARMv6+.

>
> >> Oh I forget one last thing by reading very quickly source code I could
> >> see
> >> that you need to find stack address on different platforms but it seems
> >> that on existing code for MSWINCE you are using an approximate method.
> >
> > At present, GC uses for WinCE the same approach as for Win32. The
> problems
> > could arise if GC_INIT() would be called from a deeply recursive func
> (so
> > that the stack committed space has grown) - but this could hardly occur
> in
> > practice.
> >
> >> Microsoft release sources of windows ce OS(see Platform Builder)
> >> and from it you can see that to retrieve stack bottom you can use the
> >> following code :
> >>
> >> void *os_query_stackBottom()
> >> {
> >>    const LPBYTE PUserKData = cast(LPBYTE)0xFFFFC800;
> >>
> >>     DWORD dwStackBase;
> >>     BOOL bKmode;
> >>
> >>     bKmode = SetKMode(TRUE);
> >>     dwStackBase = *(cast(DWORD*) (*(cast(DWORD*)(PUserKData + 0x094)) +
> >> 0x1C));
> >>
> >>     SetKMode(bKmode);
> >>     return cast(void *)dwStackBase;
> >> }
> >>
> >> You just need to know that wince kernel is always loaded at the same
> >> address on ARM architecture
> >> (0xFFFFC800) and that from it we can get stack address.
> >> If my memory serves me right, stack is descending (from high address
> to
> >> low address) so
> >> function is called stackBottom but could be renamed stackBound.
> >> I could give you more information if you need to.
> >
> > Is this specific to ARM only? Is it working for all recent WinCE
> versions
> > (say, since v3.0)? Is it for main thread only?
>
> Yes it's specific to ARM but I could give you methods for SH and x86
> platforms if you like.
> It's working as long as kernel doesn't change so the method I am giving
> works on arm wince 5.0 kernels
> (it means it should work on windows mobile 5.x and 6.5).

So, this is not for WinCE 6+, right?

Is this working for all ARM architectures?

Is this for UNDER_CE mode (or would work for the emulation too)?

IMHO, the code is very arch-specific (much more than that for cygwin). Let's Hans decide whether we should include in os_dep.c (even as a commented out code, just not to loose the algorithm). I'm not a deep WinCE expert... IMHO, if included, it should be accomplished with comments like: only for arm, not for wince emulation, only for wince 5, only for main thread, ...

PS. I've looked thru the patch. Everything suggested I've done already but in some more general way (it works with and without UNDER_CE, with and without UNICODE options - just for case WinCE would accept Ansi API too ;) )... Also: having malloc/free() calls looks a bit ugly - it's better to use GC_malloc[_internal] instead. One more thing - "if (atext) { ... } atext[asize] = '\0';" is a SEGV bug.

Bye.


More information about the Gc mailing list