buffer.c:372 error: unsupported non standard concatenation of string literals
-std=c11 is set. Fixed by explicitly defining string as L"%XH". Not sure if ok. uL"%XH" is not supported too. Says uL was not declared.
jit.c:3908 unknown function setjmp, did you mean _setjmp
Also I need winxp support (don’t ask) so I have to change sys.c line 130 from
int len = GetSystemDefaultLocaleName(loc,LOCALE_NAME_MAX_LENGTH);
to
int len = GetLocaleInfo( GetSystemDefaultLCID(), (LCTYPE)NULL, loc, LOCALE_NAME_MAX_LENGTH );
and I’m not sure if they are equivalent.
Welp, something is not ok
class Main {
static function main() {
var a;
for ( i in 0 ... 10 ) {
a = []; // must be an allocation?
a.push( i );
trace( a[ 0 ] ); // must be trace
}
Sys.println( 'done' );
}
}
Traces ok, prints ‘done’ and crashes with memory access violation. Same with current 1.9 straight from github. This one does work with 1.7, but then there is another thing going on which I can’t reproduce because this thing shadows it.
Actually, it may work with 1.7 because I’ve deleted almost all memory freeing calls that were happening right before exiting vm, because first VirtualFree freed all the memory, and hl was crashing on subsequent free calls. I decided to just comment those calls because program would exit and os would free the memory anyway.
Yeah, it’s the same, except 1.7 crashed every time. Inside hl_module_free() first call to hl_free_executable_memory() somehow kills m, and next m->function_indexes crashes because m points to nowhere.
Ok.
alloc_exec_mem: ptr AB0000, start_address: 0, size: 65536
jit_code: module 9EE568, code AB0000
module base: 9EE568
m->codesize: 65536
m->code address: 9B8FA4
m->functions_indexes: 3FF548
m->functions_ptrs: 9EE7A0
m->ctx.function_types: 9B0048
m->globals_indexes: 9EE5A0
m->globals_data: 9EE6A0
AB0000 is what is returned by alloc_executable_memory and code address is what actually gets passed into free_executable_memory. And module base address somehow ends being in “executable memory”. And the only function which allocs this memory is hl_jit_code which does not write into m->code, and m->code is already set at this point and not touched until the end of the program.
And also it seems like adding uprintf( L"alloc_page_mem: ptr %X, addr %X, size %d\n", ptr, start_address, size ); after VirtualAlloc inside gc_alloc_page_memory() somehow fixes the issue. Addresses still do not make much sense though, so maybe there is another example where it will crash.