| Age | Commit message (Collapse) | Author |
|---|
|
from code_SUITE:upgrade
|
|
|
|
A step toward better integration of hipe load and purge
Highlights:
* code_server no longer needs to call hipe_unified_loader:post_beam_load/1
Instead new internal function hipe_redirect_to_module()
is called by loading BIFs to patch native call sites if needed.
* hipe_purge_module() is called by erts_internal:purge_module/2
to purge any native code.
* struct hipe_mfa_info redesigned and only used for exported
functions that are called from or implemented by native code.
A list of native call sites (struct hipe_ref) are kept for each hipe_mfa_info.
* struct hipe_sdesc used by hipe_find_mfa_from_ra()
to build native stack traces.
|
|
|
|
The specifications for functions that load code in the 'code'
module (e.g. code:load_file/1) have some problems:
* The specs claim that the functions can return {error,on_load}, but
they never do. However, they can return {error,on_load_failure} if
the -on_load function in a module fails.
* The specs claim that the functions can return {error,native_code},
but they never do.
While we are it, also extend the on_load_errors/1 test case to test
that the load functions return {error,on_load_failure} when an
-on_load function fails.
|
|
|
|
Modules in the kernel, stdlib, and compiler applications are by
default "sticky", meaning that the code server will refuse to
re-load them.
The pre-loaded modules (those that are part of the run-time system
itself, such as 'erlang') are, however, not sticky. They used to be
sticky a long time ago when the pre-loaded modules were part of
the kernel application. Now they are part of the erts application.
Since re-loading a pre-loaded module can be catastrophic (especially
re-loading the 'erlang' module), the pre-loaded modules must be
sticky. Furthermore, it should not be allowed to unstick them.
The sticky_dir/1 test case in code_SUITE is never actually run and
is broken. Rewrite it.
|
|
For now we only test beam as hipe doesn't pass the test
|
|
|
|
In embedded mode, all on_load handlers will be called after
loading all modules but before starting any servers. Therefore,
if an on_load handler calls any function in the code module that
calls the code server (such as code:priv_dir/1), there will be a
deadlock because the code server has not yet been started.
Fix this problem by invoking the on_load handlers after
having started most servers in the kernel application.
|
|
Add first batch of tests for code:clash/0.
Signed-off-by: Tuncer Ayaz <[email protected]>
|
|
|
|
An on_load function is supposed to return 'true' to indicate
that the module should be loaded, and 'false' if it should be
unloaded. But returning any other term, as well as causing an
exception, will also unload the module.
Since we don't like boolean values mixed with other values,
change the expected return value as follows:
* If 'ok' is returned, the module will remain loaded and become
callable.
* If any other value is returned (or an exception is generated),
the module will be unloaded. Also, if the returned value is
not an atom, send a warning message to the error_logger
(using error_logger:warning_msg/2).
The new interpretation of the return value means that an on_load
function can now directly return the return value from
erlang:load_nif/2.
|
|
|
