Re: SMP support

Hello Brent,

Just to let you know, Damien is working on it right now. You can check 
his repos here [1].
Join IRC to help with the remaining tasks.

1) https://git.zammit.org/gnumach-sv.git/

Le 2026-01-16 07:04, Brent W. Baccala a écrit :

> Dear all -
> 
> I had a publication deadline to meet last month, so I didn't put any 
> work into Hurd.  Now I'm back on it a bit.
> 
> I'll let Claude report on the progress.  Remember, my idea is to get 
> Claude to be able to describe how to get x64 smp support running so 
> that somebody can easily do it, but without using any code authored by 
> Claude.
> 
> The only thing I'd add to Claude's report (pasted below) is that I'm 
> struggling to get GDB to reliably set breakpoints on the kernel.  It 
> works to a point, and I don't know exactly what point that is, but I 
> can certainly `hbreak` on `thread_start` and it will catch the first 
> two calls to `thread_start`, but after that it doesn't return anymore 
> for breakpoints or `next` or `step`.  What you can do is step by 
> machine instructions using `si`, and you can step all the way through 
> the kernel until it transfers to user space.
> 
> Fixing the debugger would really be nice, but I don't know all of the 
> interactions with qemu that's causing this.
> 
> Anyway, here's Claude's report:
> 
> Subject: GNU Mach x86_64 SMP Development Status Report
> 
> Hello,
> 
> I'm writing to report on progress with x86_64 SMP support for GNU Mach.
> 
> ## Status Summary
> 
> The x86_64 kernel now boots successfully and transitions to userspace. 
> The kernel can:
> - Boot and initialize all subsystems
> - Launch the first kernel thread via Load_context()
> - Create additional threads during bootstrap
> - Load ELF executables via the bootstrap process
> - Transition to userspace (confirmed by seeing instruction pointer in 
> low memory)
> 
> The system appears to hang after the userspace transition, though this 
> may be the bootstrap task running but not producing output.
> 
> ## Temporary Simplifications
> 
> To achieve this progress, three main workarounds were implemented:
> 
> 1. **CPU detection always returns 0** - Forces single-CPU mode by 
> hardcoding all CPU number detection macros all CPU number detection 
> macros
> 
> 2. **Per-CPU data bypasses %gs segment** - Changed `#if NCPUS > 1` to 
> `#if NCPUS > 100` in percpu.h files, forcing direct access to 
> percpu_array[0] instead of using %gs:offset addressing
> 
> 3. **Assembly MY() macro matches C code** - Changed from 
> `%gs:PERCPU_##stm` to `(percpu_array+PERCPU_##stm)` to use the same 
> fallback as C code
> 
> These workarounds disable true SMP functionality but prove the core 
> kernel works.
> 
> ## Key Bugs Fixed
> 
> **Array indexing scale factor mismatch**: The CX() macro used scale 
> factor 8 for all per-CPU arrays, but some arrays (curr_ipl, need_ast) 
> contain 4-byte integers, not 8-byte pointers. Split into CX() for 
> 4-byte arrays and CX8() for 8-byte pointer arrays.
> 
> **Segment register inconsistency**: Assembly code was using %gs: 
> addressing while C code used direct array access, causing segment 
> faults. Made both use the same mechanism.
> 
> **Type mismatches**: Fixed several int/long type mismatches (cpu_set, 
> in_interrupt) and corrected stack alignment from -4 to -16 bytes.
> 
> ## Architecture Challenges
> 
> Main differences from i386:
> - x86_64 long mode uses flat memory model, can't use %cs: segment 
> overrides
> - Pointer sizes: 8 bytes vs 4 bytes affects array indexing
> - Stack alignment: 16-byte vs 4-byte requirement
> - %gs segment must be properly initialized via GDT/MSR for per-CPU data
> 
> ## Outstanding Questions
> 
> 1. Is the system actually hung, or is the bootstrap task running 
> without producing console output?
> 2. What's the next step after userspace transition - does execution 
> continue normally?
> 3. Should we focus on getting console output from userspace, or on 
> re-enabling SMP features?
> 
> ## Next Steps
> 
> Once userspace execution is confirmed working, incrementally re-enable 
> SMP features:
> 1. Restore proper CPU detection (test with 1 CPU first)
> 2. Initialize %gs segment and restore %gs-based per-CPU access
> 3. Test with multiple CPUs
> 
> Documentation has been created in CLAUDE.md (development log), 
> 15Jan2026.md (debug register investigation), and MACH_KDB_GUIDE.md 
> (kernel debugger guide).
> 
> Best regards
> 
> On Mon, Nov 24, 2025 at 7:00 PM Brent W. Baccala <[email protected]> 
> wrote:
> 
> On Mon, Nov 24, 2025 at 4:26 PM Samuel Thibault <[email protected]> 
> wrote:
> Hello,
> 
> Dr. Arne Babenhauserheide, le lun. 24 nov. 2025 07:41:27 +0100, a 
> ecrit:
>> "Brent W. Baccala" <[email protected]> writes:
>>> What's the project's policy regarding AI-generated code?
>> 
>> Not my call to make, but in the Emacs list there's been a long
>> discussion, and if I understand the conclusion: the legal situation is
>> complicated, and proprietary AI as service is fundamentally at odds 
>> with
>> Free Software values:
> 
> Yes, and I see it as rather dangerous to include code that was 
> generated
> by an AI. Notably for code which doesn't exist in many variants on the
> Internet, Claude would most probably copy/paste something rather than
> mixing up something which would be far enough from existing code to be
> unencumbered by copyright. This is not something we can afford putting
> in the very kernel of an OS
> 
> I agree.  Let me suggest this:  If I get it working (that's a big "if", 
> of course), I'll tell it to generate a list of instructions on how to 
> do it, without including any code, and post that.  Then, somebody else 
> can actually code it for the kernel, following the instructions as they 
> wish.
> 
> Let me clarify something, though.  This is Claude Code, which is 
> agentic (i.e, it can use tools).  It runs locally in node.js and 
> interacts with the Anthropic servers via an API.  That means that it 
> has access to the gnumach source code and can make changes to it.  The 
> most likely source of code for it to crib from is gnumach itself.
> 
> My hope is that since it's got working SMP code it can look at, and 
> working 64-bit code it can look at, it can figure out how to combine 
> them.  I wouldn't expect a non-agentic AI to do that.
> 
> agape
> brent