2018-09-05 12:01:35 +02:00
|
|
|
pub type OrPageFault<T> = Result<T, ()>;
|
|
|
|
|
|
2018-09-04 14:49:38 +02:00
|
|
|
macro_rules! return_false_on_pagefault {
|
|
|
|
|
($expr:expr) => {
|
|
|
|
|
match $expr {
|
|
|
|
|
Ok(v) => v,
|
|
|
|
|
Err(()) => return false,
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
Handle pagefaults without JS exceptions
This commit makes the return type of most basic memory access primitives
Result, where the Err(()) case means a page fault happened, the
instruction should be aborted and execution should continue at the page
fault handler.
The following primites have a Result return type: safe_{read,write}*,
translate_address_*, read_imm*, writable_or_pagefault, get_phys_eip,
modrm_resolve, push*, pop*.
Any instruction needs to handle the page fault cases and abort
execution appropriately. The return_on_pagefault! macro has been
provided to get the same behaviour as the previously used JS exceptions
(local to the function).
Calls from JavaScript abort on a pagefault, except for
writable_or_pagefault, which returns a boolean. JS needs to check
before calling any function that may pagefault.
This commit does not yet pervasively apply return_on_pagefault!, this
will be added in the next commit.
Jitted code does not yet properly handle the new form of page faults,
this will be added in a later commit.
2018-08-14 23:07:54 +02:00
|
|
|
macro_rules! return_on_pagefault {
|
|
|
|
|
($expr:expr) => {
|
|
|
|
|
match $expr {
|
|
|
|
|
Ok(v) => v,
|
|
|
|
|
Err(()) => return,
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
}
|
