diff options
author | Tuncer Ayaz <[email protected]> | 2010-10-04 23:34:06 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2010-10-05 14:28:15 +0200 |
commit | fb5e332483a6f180bfbfe8bac33edf1b7b386b1a (patch) | |
tree | 829aef96374c0d80855fa057b57d8594dde58e70 /erts/start_scripts/start_clean.rel.src | |
parent | 3cfec17ff7aff97c5ec862a8b9e97d245849f9c3 (diff) | |
download | otp-fb5e332483a6f180bfbfe8bac33edf1b7b386b1a.tar.gz otp-fb5e332483a6f180bfbfe8bac33edf1b7b386b1a.tar.bz2 otp-fb5e332483a6f180bfbfe8bac33edf1b7b386b1a.zip |
error_handler: add no_native compiler directive
As suggested by Mikael Pettersson:
"I agree there _may_ be a recursion between the native-traps-to-beam
mechanism and the error_handler module. However, the real problem is
that the chosen mechanism (point to target MFA's BEAM code) isn't
flexible enough to handle newer features like on_load or (apparently)
a native-mode error_handler.
My planned fix is to make remote calls link to the target's Export*
instead, just like BEAM does, which should solve the problems. This
will however require HiPE to use different kinds of trap-to-beam stubs
for remote and local calls, since local calls must not and often
cannot go via Export entries.
A simpler workaround for the error_handler issue (which I couldn't
reproduce) is to just never compile error_handler to native code. It's
not like there's a lot to gain by doing that. Please try the patch
below."
Patch has been tested and confirmed to make --enable-native-libs
useable.
Signed-off-by: Mikael Pettersson <[email protected]>
Acked-by: Tuncer Ayaz <[email protected]>
Diffstat (limited to 'erts/start_scripts/start_clean.rel.src')
0 files changed, 0 insertions, 0 deletions