Kernel: Fix Clang not initializing `s_bsp_processor` correctly

Initializing the variable this way fixes a kernel panic in Clang where
the object was zero-initialized, so the `m_in_scheduler` contained the
wrong value. GCC got it right, but we're better off making this change,
as leaving uninitialized fields in constant-initialized objects can
cause other weird situations like this. Also, initializing only a single
field to a non-zero value isn't worth the cost of no longer fitting in
`.bss`.

Another two variables suffer from the same problem, even though their
values are supposed to be zero. Removing these causes the
`_GLOBAL_sub_I_` function to no longer be generated and the (not
handled) `.init_array` section to be omitted.

1 files changed, 1 insertions, 0 deletions

diff --git a/Kernel/Arch/x86/common/Processor.cpp b/Kernel/Arch/x86/common/Processor.cpp
index 1b8de25d1b..11affd1bed 100644
--- a/Kernel/Arch/x86/common/Processor.cpp
+++ b/Kernel/Arch/x86/common/Processor.cpp
@@ -305,6 +305,7 @@ UNMAP_AFTER_INIT void Processor::early_initialize(u32 cpu)
 
     m_invoke_scheduler_async = false;
     m_scheduler_initialized = false;
+    m_in_scheduler = true;
 
     m_message_queue = nullptr;
     m_idle_thread = nullptr;