[Gc]: mingw32ce patch

Vincent R. forumer at smartmobili.com
Wed Sep 30 06:34:27 PDT 2009


On Wed, 30 Sep 2009 14:56:56 +0400, Ivan Maidanski <ivmai at mail.ru> wrote:
> 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).
> 

So when you compile it with mingw32ce or cegcc what command line are you
using exactly ?



>>
>> 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?
> 
No but I suppose I could find the same for WinCE 6+

> Is this working for all ARM architectures?
> 
Need to check but I suppose so

> Is this for UNDER_CE mode (or would work for the emulation too)?
> 
Works on both since emulator is an ARM emulator


> 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, ...
>
OK but I need to find my old sample code when I was trying to port D
language to wince,
I already played with that kind of stuff.


> 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.

Thanks for the bug report


More information about the Gc mailing list