[Gc] mingw32ce patch

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


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

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'




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

> 
>>
>> However now I have one error left :
>> /cygdrive/c/downloads/gc-7.2alpha2.tar/gc-7.2alpha2_NEW/misc.c:765:
>> undefined reference to `GC_thr_init'
>>
>> but I don't know exactly what to do with it so before to go any further
I
>> would like your comments.
> 
> Everything seems to work (as report others) except may be - configure (I
> haven't tried) - If you care send us a patch for it.
> 
> At present, I use the following to build a DLL:
> gcc -O2 -fno-strict-aliasing -Wall -DALL_INTERIOR_POINTERS
> -DJAVA_FINALIZATION -DGC_GCJ_SUPPORT -DNO_DEBUGGING -DGC_THREADS
-DNDEBUG
> -I include -I libatomic_ops/src -DUSE_MUNMAP -DTHREAD_LOCAL_ALLOC
> -march=armv6 -DPARALLEL_MARK -shared -DGC_DLL -o gc.dll -s *.c
> 
> There may be some problems with compiling for some WinCE 6.0 custom
builds
> because GCC doesn't support SEH.
> 
Yes I know that.

>> 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 rightn, 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).




More information about the Gc mailing list