Good evening, again -
There's something I forgot to write about in my last post.
Use of Claude is controversial.
The model has been trained on pirated content. Anthropic then paid $1.5bn,
the largest copyright settlement ever, to pay each of the authors something
like $30,000 each.
I have to admit, the neural network in my brain has also been trained on
pirated content, for better or for worse.
Anyway, some people object to using Claude at all. It's definitely a bit
shady what they did.
agape
brent
On Fri, Jan 16, 2026 at 12:04 AM Brent W. Baccala <[email protected]>
wrote:
> 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
>>
>>
>
