-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExternalModulesTests.testReturningAValue: segfault in math_sqrt() #70
Comments
This is because dynamic_cast at https://github.com/marekjm/wudoovm/blob/23b5e76dbc6abf25152b830f4f8b1e4f7cb61db4/sample/asm/external/math.cpp#L12 fails:
|
Somewhat related info: https://gcc.gnu.org/faq.html#dso |
But whenever I am using There is a One Definition Rule in the [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf](C++11 standard %28liked n3337%29), but my reading of paragraph 3.2 allows for the case we have here. Until this is researched properly it looks like creating plugins using wudoovm types may be not portable. |
Contents of relevant sections of (from nm(1))
From
|
Well, the thing I am about to suggest may be stupid but... How about instead of relying on standard library's typechecking abilities we use machine's own? The object that function My reasoning is that if What do you think? |
Something like this? https://github.com/sass/libsass/blob/master/sass_values.h#L16-L28 |
Kinda. Objects in Viua provide virtual Could you check if commit ce04c1d works for you? |
Yes, the test passes. Still trying to find out the cause for this (I think I've had some strange |
OK, so "the failing test" part of the issue is fixed. I will leave the issue open, though, and look for info why this should fail with |
Here is a little piece of code to test whether https://github.com/saper/dynamic_cast Output on Linux:
Output on FreeBSD:
More precisely, it also works on FreeBSD when compiling with g++ and using newer |
Filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201784 to FreeBSD |
When we pass -Wl,--dynamic-list-cpp-typeinfo (or -Wl,--export-dynamic) then the run time type information for C++ classes is exported from the program ("cpu", "dis" etc.) to any dynamically shared libraries. Therefore C++ type definitions are available and consistent with what the plugin may use. We can even produce a specific list if desired, by using -Wl,--dynamic-list More information: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201784 Big thanks to David Chisnall (@davidchisnall) for helping to point this out. Fixes: marekjm#70
When we pass -Wl,--dynamic-list-cpp-typeinfo (or -Wl,--export-dynamic) then the run time type information for C++ classes is exported from the program ("cpu", "dis" etc.) to any dynamically shared libraries. Therefore C++ type definitions are available and consistent with what the plugin may use. We can even produce a specific list if desired, by using -Wl,--dynamic-list More information: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201784 Big thanks to David Chisnall (@davidchisnall) for helping to point this out. Fixes: #70
I'm closing the issue. Thanks for bringing up that there were some issues with the VM running on FreeBSD. |
It actually turns out not to be a bug and can be mitigated by controlling dynamically exported symbols, which is a good thing that helps to keep stable APIs between modules anyway. |
The text was updated successfully, but these errors were encountered: