[Gc] Porting GC to Win64

Matthew Bromberg mattcbro at earthlink.net
Fri Dec 29 14:47:05 PST 2006


I thought perhaps I might hack my way to a workable version of the 
garbage collector
on windows XP 64, running in 64 bit mode.  Perhaps the issues are a bit 
more complex than I anticipated.

I am using the 64 bit compiler in the recent microsoft windows platform 
sdk.  (Version 14.00.40310.41 for AMD64).
I am modifying one of the makefile build scripts and am using cl.exe 
with the /Wp64 flag to tag places where there
are possibly dangerous bit truncations.  There are many places where the 
size of unsigned long is assumed to be the
same as the size of a pointer.  This is not the case for Win64.  long is 
32 bits in fact so that the size of structures etc. containing longs
might be bit compatible with Win32.  So I replaced these occurrences 
with GC_word and in some cases GC_signed_word.

Unfortunately the new compiler does not have inlined asm so I used flat 
assembler (fasm.exe) to assemble those components into
object files for later linking.  Eventually I got it to compile, 
although I could not remove all warnings.  There are some issues with 
GC_printf,
which apparently always assumes that pointers are sizeof(long).  Also 
the global variable GC_size_map[] has type unsigned int and
it doesn't make sense to extend it to GC_word.

I created a static linked library (linking to /MT instead of /MD) 
because the platform SDK seems to crash if it has to load the system 
msvcrt.dll. (Perhaps the one supplied in the SDK works, I haven't 
figured out how to force windows to use a different  msvcrt.dll).  
Finally after running one of my libraries that makes heavy use of the
garbage collector I got an access violation here (winddbg output):

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" 
referenced memory at "0x%08lx". The memory could not be "%s".

WRITE_ADDRESS:  0000000000000024

BUGCHECK_STR:  ACCESS_VIOLATION
......

FOLLOWUP_IP:
settest!GC_generic_malloc+c5 [d:\projects\pamcomp\csrc\gc6.8\malloc.c @ 206]
00000000`00407745 4533c0          xor     r8d,r8d

FAULTING_SOURCE_CODE: 
    word lw;
    word n_blocks;
    GC_bool init;
    lw = ROUNDED_UP_WORDS(lb);
    n_blocks = OBJ_SZ_TO_BLOCKS(lw);
    init = GC_obj_kinds[k].ok_init;

   202:     n_blocks = OBJ_SZ_TO_BLOCKS(lw);
   203:     init = GC_obj_kinds[k].ok_init;
   204:     DISABLE_SIGNALS();
   205:     LOCK();
 >  206:     result = (ptr_t)GC_alloc_large(lw, k, 0);
   207:     if (0 != result) {
   208:       if (GC_debugging_started) {
   209:         BZERO(result, n_blocks * HBLKSIZE);
   210:       } else {
   211: #           ifdef THREADS


-------------------------------------------------------------
k is apparently an input argument to GC_generic_malloc().  Since I'm 
just hacking the source here,  I'm a bit out of my league in trying to 
resolve some of these issues.
Any help would be appreciated.



More information about the Gc mailing list