Closed intrigus closed 6 years ago
Emscripten support is added in commits 7d2905e, 4eaea0a. But it seems it was not tested on mac host. Could you please try the following fix?
diff --git a/os_dep.c b/os_dep.c index 0f22b80..398e974 100644 --- a/os_dep.c +++ b/os_dep.c @@ -1179,7 +1179,7 @@ GC_INNER size_t GC_page_size = 0; # define GET_MAIN_STACKBASE_SPECIAL #elif !defined(BEOS) && !defined(AMIGA) && !defined(OS2) \ && !defined(MSWIN32) && !defined(MSWINCE) && !defined(CYGWIN32) \ - && !defined(GC_OPENBSD_THREADS) \ + && !defined(STACK_NOT_SCANNED) && !defined(GC_OPENBSD_THREADS) \ && (!defined(GC_SOLARIS_THREADS) || defined(_STRICT_STDC))
# if defined(LINUX) && defined(USE_GET_STACKBASE_FOR_MAIN)
Compiling works with this patch.
Linking with my code also works, but fails at runtime.
Test code is from https://github.com/ivmai/bdwgc/blob/master/tests/leak_test.c saved as gc_test.c
$: emcc -Iinclude .libs/libgc.dylib gc_test.c -o test.html
warning: unresolved symbol: llvm_frameaddress
pre-main prep time: 68 ms
printErr @ test.html:1249
test.html:1249 GC_get_stack_base failed
printErr @ test.html:1249
test.html:1249 exception thrown: abort() at Error
at jsStackTrace (file:///Users/simon/Downloads/bdwgc/test.js:1111:13)
at stackTrace (file:///Users/simon/Downloads/bdwgc/test.js:1128:12)
at Object.abort (file:///Users/simon/Downloads/bdwgc/test.js:28704:44)
at _abort (file:///Users/simon/Downloads/bdwgc/test.js:1711:22)
at _GC_get_main_stack_base (file:///Users/simon/Downloads/bdwgc/test.js:18380:3)
at _GC_init (file:///Users/simon/Downloads/bdwgc/test.js:17556:10)
at _main (file:///Users/simon/Downloads/bdwgc/test.js:20012:2)
at Object.asm._main (file:///Users/simon/Downloads/bdwgc/test.js:28339:19)
at Object.callMain (file:///Users/simon/Downloads/bdwgc/test.js:28578:30)
at doRun (file:///Users/simon/Downloads/bdwgc/test.js:28642:60)
printErr @ test.html:1249
test.js:227 Uncaught abort() at Error
at jsStackTrace (file:///Users/simon/Downloads/bdwgc/test.js:1111:13)
at stackTrace (file:///Users/simon/Downloads/bdwgc/test.js:1128:12)
at Object.abort (file:///Users/simon/Downloads/bdwgc/test.js:28704:44)
at _abort (file:///Users/simon/Downloads/bdwgc/test.js:1711:22)
at _GC_get_main_stack_base (file:///Users/simon/Downloads/bdwgc/test.js:18380:3)
at _GC_init (file:///Users/simon/Downloads/bdwgc/test.js:17556:10)
at _main (file:///Users/simon/Downloads/bdwgc/test.js:20012:2)
at Object.asm._main (file:///Users/simon/Downloads/bdwgc/test.js:28339:19)
at Object.callMain (file:///Users/simon/Downloads/bdwgc/test.js:28578:30)
at doRun (file:///Users/simon/Downloads/bdwgc/test.js:28642:60)
llvm_frameaddress is defined as this, but I'm not sure if it's even called at runtime because it's not in the stacktrace. (Maybe it has been inlined, don't know)
function _llvm_frameaddress() {
Module['printErr']('missing function: llvm_frameaddress'); abort(-1);
}
Anyway thanks for you help :) I'm not sure if this is a bug in bdwgc or in emscripten, but if it works for Unity it should probably also work for me :)
Will open an issue in emscripten, if it's indeed a problem with emscripten. If you need anything else from I'm happy to provide it.
Have you checked the master with the given diff or gc 7.6.0 (with the diff)?
I have checked bdwgc 7.6.0 with the diff This compiles fine but fails at runtime. (As stated here https://github.com/ivmai/bdwgc/issues/163#issuecomment-304704885 ) Without the patch it didn't even compile.
I'm going to try bdwgc master with the diff and also emscripten master with bdwgc master.
Any other suggestions?
Judging from the generated javascript GC_get_stack_base
is not implemented in emscripten (GC_UNIMPLEMENTED = 3) that's why this line fails with an abort https://github.com/ivmai/bdwgc/blob/408ea9f873e48f6001f717b53fc0dec9a2d0f6d5/os_dep.c#L1467
function _GC_get_stack_base($0) {
$0 = $0|0;
var $1 = 0, label = 0, sp = 0;
sp = STACKTOP;
STACKTOP = STACKTOP + 16|0; if ((STACKTOP|0) >= (STACK_MAX|0)) abortStackOverflow(16|0);
$1 = $0;
STACKTOP = sp;
return 3; // GC_UNIMPLEMENTED @line 1454 "os_dep.c"
}
function _GC_get_main_stack_base() {
var $0 = 0, $1 = 0, $2 = 0, $3 = 0, $4 = 0, label = 0, sp = 0;
sp = STACKTOP;
STACKTOP = STACKTOP + 16|0; if ((STACKTOP|0) >= (STACK_MAX|0)) abortStackOverflow(16|0);
$0 = sp;
$1 = (_GC_get_stack_base($0)|0); //@line 1466 "os_dep.c"
$2 = ($1|0)!=(0); //@line 1466 "os_dep.c"
if ($2) { // GC_get_stack_base(&sb) != GC_SUCCESS
$3 = HEAP32[138]|0; //@line 1467 "os_dep.c"
FUNCTION_TABLE_vi[$3 & 31](5159); //@line 1467 "os_dep.c"
_abort(); //@line 1467 "os_dep.c" // ABORT("GC_get_stack_base failed");
// unreachable; //@line 1467 "os_dep.c"
} else {
$4 = HEAP32[$0>>2]|0; //@line 1469 "os_dep.c"
STACKTOP = sp;return ($4|0); //@line 1469 "os_dep.c"
}
return (0)|0;
}
ad 1. 7d2905e Works fine. ad 2. Going to try now.
Hmm. Discard 2. Could you please try 4eaea0a ? If it works then bisect starting from 4eaea0a and finishing at gc7_6_0.
I recall poking a codebase that built Boehm some time earlier. Since JavaScript/asm.js/WebAssembly is not able to access the function call stack or the local data stack, it is not possible for Boehm to perform its stack walking operation to find which objects are rooted by the stack. To work around that, codebases generally only do Boehm GC steps when the stack is empty so it is known that there are no objects that would be rooted by the stack, and Boehm is compiled in a mode that disables stack walking since it does not apply.
If that is already being done, and assuming the build issue is only a technicality of appeasing the compiler to see the correct symbols, then I suppose any no-op implementation might work (i.e. return stack base = address 0, stack size = 0). Alternatively, you can try hooking the functions to the pthread_attr_getstack
function (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_getstack.html) which should be functional in both singlethreaded and multithreaded builds. Though reading this stack has very different meaning than the native stack, and won't contain function local GC objects.
I made a mistake, I thought that I use version 7.6.0 but my version is much newer. Anyway I found these two issues. One is new the other one is already known. I didn't yet bisect https://github.com/ivmai/bdwgc/issues/163#issuecomment-304704885 because I don't know whether it may be solved by solving (1) or (2).
@ivmai I've bisected and found two issues.
See https://gist.github.com/intrigus/ef1f0bf9f19f164611f9a1c97ac58e05#file-gistfile2-txt
https://gist.github.com/intrigus/ef1f0bf9f19f164611f9a1c97ac58e05#file-gistfile1-txt
Thank you, @juj. I will add a comment to gcconfig.h
@intrigus, I have analyzed the commits you referenced. Please try the following fix (for master):
diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h index bf17dd63..7aa9e504 100644 --- a/include/private/gcconfig.h +++ b/include/private/gcconfig.h @@ -817,8 +817,8 @@ # define OS_TYPE "EMSCRIPTEN" # define CPP_WORDSZ 32 # define ALIGNMENT 4 -# define DATASTART (ptr_t)NULL -# define DATAEND (ptr_t)NULL +# define DATASTART (ptr_t)ALIGNMENT +# define DATAEND (ptr_t)ALIGNMENT # define STACK_NOT_SCANNED # endif
diff --git a/os_dep.c b/os_dep.c index 0f22b80e..d941afcd 100644 --- a/os_dep.c +++ b/os_dep.c @@ -1252,7 +1252,7 @@ GC_INNER size_t GC_page_size = 0; # endif # endif } -# elif defined(CPPCHECK) +# elif defined(STACK_NOT_SCANNED) || defined(CPPCHECK) result = NULL; # else # error None of HEURISTIC and STACKBOTTOM defined!
After applying the diff it compiles but fails at runtime with yet another error. Will have to bisect again :)
@ivmai @juj @intrigus you may wish to take a look at the discussion over here: https://github.com/WebAssembly/binaryen/issues/1312#issuecomment-351272048
It appears that we could get a workable solution for getting this going as per @kripken via binaryen for emscripten.
Is there anything to do regarding this issue?
@ivmai I've had some other pressing issues that have precluded my doing anything here. Has anyone been able to get this working, and if so or otherwise, could you post your findings?
Has anyone been able to get this working, and if so or otherwise, could you post your findings?
I think all the mentioned commits are included in v7.6.4 release
Thanks very much @ivmai. It would be interesting to see if anyone has a blog post or a demo of this working to see the finer points as it now stands in this usecase.
Hello, I'm trying to compile bdwgc for emscripten, but it fails during compilation. If you need more information I'm happy to provide it.
This is the error:
Used versions and more information:
emcc --version
The bdwgc version is 7.6.0. I'm running the following commands on my Mac.