Skip to content

prevent cyclic Expects warning#2366

Open
mazunki wants to merge 4 commits into
includeos:mainfrom
mazunki:expects-recursion
Open

prevent cyclic Expects warning#2366
mazunki wants to merge 4 commits into
includeos:mainfrom
mazunki:expects-recursion

Conversation

@mazunki
Copy link
Copy Markdown
Contributor

@mazunki mazunki commented Apr 8, 2026

This builds on top of #2363 due to tests.

As requested in #2361 (comment), it's better to handle cyclic faults at the exception handler. This PR fixes this, with some practical compromises.

Ideally, I would have liked to call os::panic(), but this has some issues: currently, os::panic only supports being called with const char *why, with no concept of source location or expressions.

Furthermore, it (used to) assume libc was initialized (i.e. calling printf and friends). I've added a check to prevent this being an issue, irrespective of the problem this PR solves. I think os::panic should have two interfaces: a dumb one that can be used irrespective of initialization state (that is, a simple fallback mechanism that is similar to my implementation of __expect_fail), and a complete one that accepts std::format_string and cooperates correctly with the rest of the system.

Unrelated to this, calling __arch_poweroff() does not feel good. I wanted to call os::shutdown(), but this doesn't actually trigger a shutdown unless the proper message has been sent to vmrunner. I've opened #2364 with more details about this.

@mazunki mazunki changed the title Expects recursion prevent cyclic expects warning Apr 8, 2026
@mazunki mazunki changed the title prevent cyclic expects warning prevent cyclic Expects warning Apr 8, 2026
mazunki added 4 commits May 12, 2026 15:05
it's not guaranteed that all implementations of `reboot()` are
terminating calls.

`reboot_os()`, externally defined at
`src/arch/{x86_64,i686}/apic_asm.asm` both terminate, but this seems to
be an implementation detail of the x86 architecture.
@mazunki mazunki force-pushed the expects-recursion branch from 5310776 to ae97935 Compare May 12, 2026 13:05
@mazunki
Copy link
Copy Markdown
Contributor Author

mazunki commented May 12, 2026

rebased to sync with main

@alfreb
Copy link
Copy Markdown
Contributor

alfreb commented May 12, 2026

This looks good - but can you help me figure out how to test it? I will, but might not be today. Also, I agree that we should have an early and late panic, where only the late one expects libc to be initialized- although we could just check if it is. I think there's a boolean for that somewhere.

@mazunki
Copy link
Copy Markdown
Contributor Author

mazunki commented May 12, 2026

We do have kernel::libc_initialized(), but I'm not sure that accounts for all early initialization being ready: 93efffa does exactly that.

I tested this by manually lying in src/kernel/multiboot.cpp::_multiboot_memory_end() (i.e. immediately return os::Arch::max_canonical_addr;) . I'm not sure if there's a clean way to test this, as this should really only trigger if something is /really wrong/ with the early boot process.

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

Successfully merging this pull request may close these issues.

2 participants