Skip to content
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

syscall_handler entry point is wrong, causes page fault in release mode #14

Closed
kevinaboos opened this issue Jan 2, 2018 · 2 comments
Closed

Comments

@kevinaboos
Copy link
Member

the page fault occurs in switch_to(). Haven't yet found why it occurs, but it is very consistent. Here is the output:

EXCEPTION: PAGE FAULT while accessing 0x8
error code: CAUSED_BY_WRITE
ExceptionStackFrame {
    instruction_pointer: 0xffffffff80108a01,
    code_segment: 8,
    cpu_flags: 0x2,
    stack_pointer: 0xffffffff80154018,
    stack_segment: 16
}

We should also find out which commit caused this to occur, and then diff it with the next one. Who wants to do some differential debugging?

kevinaboos added a commit that referenced this issue Mar 5, 2018
Removed old cruft of VGA buffer character direct writes.
Release mode sort of works now (Issue #14), but causes a page fault for syscalls. Probably something related to reordering in the syscall handler.
Everything else works in release mode too.
kevinaboos added a commit that referenced this issue Mar 5, 2018
…stack frames are kept. Otherwise, it will build without stack frames, causing a page fault in the syscall_handler. To fix that page fault, we can use the middle (or the top quarter) of the privilege stack that is passed to enable_syscalls(), rather than using the absolute top of the stack.

This closes issue #14.
kevinaboos added a commit that referenced this issue Mar 5, 2018
…stack frames are kept. Otherwise, it will build without stack frames, causing a page fault in the syscall_handler. To fix that page fault, we can use the middle (or the top quarter) of the privilege stack that is passed to enable_syscalls(), rather than using the absolute top of the stack.

This closes issue #14.
@kevinaboos
Copy link
Member Author

Update: syscall_handler causes a problem in release mode because positive offsets from the stack pointer are used. The problem and solutions are discussed here in my SO post: https://stackoverflow.com/questions/49125151/code-generation-for-local-stack-variables-in-release-vs-debug-mode

Basically, we need to subtract from rsp to make space for it. We also need to set rbp properly (and restore it properly at the end), just like the compiler would do for a non-naked function.

@kevinaboos kevinaboos changed the title nano_core causes page fault when built using cargo release mode syscall_handler entry point is wrong, causes page fault in release mode Jun 8, 2018
@kevinaboos
Copy link
Member Author

Closing for now, because Theseus is not focused on supporting userspace in Ring 3.

kevinaboos added a commit that referenced this issue Sep 1, 2020
Removed old cruft of VGA buffer character direct writes.
Release mode sort of works now (Issue #14), but causes a page fault for syscalls. Probably something related to reordering in the syscall handler.
Everything else works in release mode too.
kevinaboos added a commit that referenced this issue Sep 1, 2020
…stack frames are kept. Otherwise, it will build without stack frames, causing a page fault in the syscall_handler. To fix that page fault, we can use the middle (or the top quarter) of the privilege stack that is passed to enable_syscalls(), rather than using the absolute top of the stack.

This closes issue #14.
kevinaboos added a commit that referenced this issue Sep 1, 2020
Removed old cruft of VGA buffer character direct writes.
Release mode sort of works now (Issue #14), but causes a page fault for syscalls. Probably something related to reordering in the syscall handler.
Everything else works in release mode too.
kevinaboos added a commit that referenced this issue Sep 1, 2020
…stack frames are kept. Otherwise, it will build without stack frames, causing a page fault in the syscall_handler. To fix that page fault, we can use the middle (or the top quarter) of the privilege stack that is passed to enable_syscalls(), rather than using the absolute top of the stack.

This closes issue #14.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant