WIP: Port dmd and druntime to GNU/Hurd by yelninei · Pull Request #22829 · dlang/dmd

yelninei · 2026-03-27T16:06:24Z

Hi,

As announced on https://forum.dlang.org/thread/[email protected] here is my WIP PR for porting druntime and dmd to GNU Hurd.

To be able to build also #22787 is needed.

Things that I know are still a bit of a mess:

Indentation
How to add version(linux) where CRuntime_Glibc is used to mean linux + glibc.
Mix of new and old alias syntax. Some of the parts were originally against gcc-11 to be able to bootrap and I have not revised the patches yet.

I am currently quite happy with the dmd part as all tests pass on 32bit and 64bit except

dmd/compiler/test/dshell/sameenv.d : checks that 2 executables have the same environment variables but they expectedly differ in LD_ORIGIN_PATH
dmd/compiler/test/runnable_cxx/cppa.d : A warning coming from non _GLIBCXX_USE_CXX98_ABI version

For the runtime some tests still crash in pthread_join, I am not entirely sure why as the same test outside of libdruntime_ut works fine.
On x86_64 the test runner gets killed after a while with the gc suspend signal, I dont know yet why the runtime does not handle it.

I am not erntirely sure about the format for the dmd triplet as it differs from both the gnu config and llvm triplet.

I have asked people on the bug-hurd mailing list for help as well
https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00274.html
https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00275.html

There are some more things needed to bring this back into gdc,

dlang-bot · 2026-03-27T16:06:27Z

Thanks for your pull request and interest in making D better, @yelninei! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22829"

yelninei · 2026-03-27T16:58:45Z

The error from the circleci is

ERROR: Newly generated header file (/home/circleci/dmd/generated/linux/release/64/frontend.h) doesn't match with the reference header file (/home/circleci/dmd/compiler/src/dmd/frontend.h)

DETAILS:

diff --git a/home/circleci/dmd/compiler/src/dmd/frontend.h b/home/circleci/dmd/generated/linux/release/64/frontend.h
index 8e8e2fe76..479667814 100644
--- a/home/circleci/dmd/compiler/src/dmd/frontend.h
+++ b/home/circleci/dmd/generated/linux/release/64/frontend.h
@@ -7363,8 +7363,9 @@ struct Target final
         FreeBSD = 16u,
         Solaris = 32u,
         DragonFlyBSD = 64u,
-        all = 127u,
-        Posix = 125u,
+        Hurd = 128u,
+        all = 255u,
+        Posix = 253u,
     };
 
     OS os;

===============
The file `src/dmd/frontend.h` seems to be out of sync. This is likely because
changes were made which affect the C++ interface used by GDC and LDC.

I guess this is expected, is there a way to regenerate the header?

pbackus · 2026-03-27T17:30:42Z

Re: regenerating the headers, if you read a few more lines down in that error message, you will see this:

To read more about frontend.h and its usage, see src/README.md#cxx-headers-test

Which refers to https://github.com/dlang/dmd/tree/master/compiler/src#cxx-headers-test

ibuclaw · 2026-03-27T19:41:39Z

I am not erntirely sure about the format for the dmd triplet as it differs from both the gnu config and llvm triplet.

I thought dmd triplet (tuples?) matched ldc.

Historically, I guess gnu/hurd would be i*86-gnu or x86_64-gnu.

compiler/src/dmd/backend/arm/cod1.d

druntime/src/core/internal/elf/dl.d

druntime/src/core/internal/elf/io.d

druntime/src/core/stdc/config.d

druntime/src/core/sys/hurd/dlfcn.d

druntime/src/core/sys/hurd/elf.d

ibuclaw · 2026-03-27T20:00:19Z

druntime/src/core/sys/hurd/execinfo.d

+/**
+ * D header file for GNU Hurd
+ *
+ * Copyright: Copyright Martin Nowak 2012.


Wrong year, wrong copyright. :-)

If unsure, please use:

Copyright: Copyright (c) 2026 D Language Foundation

ibuclaw · 2026-03-27T20:01:46Z

druntime/src/core/sys/hurd/execinfo.d

+ *
+ * Copyright: Copyright Martin Nowak 2012.
+ * License:   $(LINK2 http://www.boost.org/LICENSE_1_0.txt, Boost License 1.0)
+ * Authors:   Martin Nowak


I assume Martin didn't author this module.

The file is a copy paste of the linux version with s/linux/hurd/

Is that enough to void the original copyright as it is clearly a derivative?

I'm not qualified to say. In isolation, I don't consider the file big enough to warrant any copyright claim.

Rather, the body of work as a whole (this PR) ought to be considered as authored by the contributor.

ibuclaw · 2026-03-27T20:06:39Z

druntime/src/core/sys/hurd/unistd.d

@@ -0,0 +1,25 @@
+module core.sys.hurd.unistd;


Some modules are missing comment headings/notices entirely. Others have inconsistent styles.

As these are newly introduced sources, I'd err towards not repeating previous bad habits, and pick one format, and use it consistently throughout all new files.

druntime/src/core/sys/linux/stdio.d

ibuclaw · 2026-03-27T20:19:48Z

druntime/src/core/sys/posix/sys/ioctl.d

 }
+else version (Hurd)
+{
+  // What is needed here?


Any part of ioctls.h or ioctl-types.h that would be needed to interact with ioctl().

druntime/src/core/sys/posix/sys/socket.d

ibuclaw · 2026-03-27T20:26:07Z

druntime/src/core/sys/posix/pthread.d

 version (CRuntime_Glibc)
 {
+  version (linux)
+  {


It looks like the outer CRuntime_Glibc is unneeded here. Just version (linux) { } else version (Hurd) { } else ... ?

Not sure, that would shadow the musl, uclibc and bionic versions on linux which are not 1:1 copies of the glibc one

ibuclaw · 2026-03-27T20:27:26Z

druntime/src/core/sys/posix/pthread.d

 version (CRuntime_Glibc)
 {
+  version (linux)


Likewise, maybe just remove the CRuntime_Glibc guard.

druntime/src/rt/sections_elf_shared.d

druntime/src/core/time.d

compiler/src/dmd/target.d

compiler/test/runnable/test22.d

yelninei · 2026-03-28T11:34:47Z

I ran detab everywhere, cleaned up a lot of things manually and then also ran dfix for the alias conversion (separate commit to make it easier to backport to earlier versions)

some things remain (especially where i need guard off linux code as that would also need to be reindented)

compiler/test/runnable/test22.d

druntime/src/core/sys/posix/sys/stat.d

yelninei · 2026-03-29T11:54:45Z

EDIT:

Adding the GCSignalsUnblock version for the gc fixes a lot more issues. The pthread ones remain.

This was not great to debug.

compiler/src/dmd/target.d

ibuclaw · 2026-03-30T20:47:38Z

EDIT:

Adding the GCSignalsUnblock version for the gc fixes a lot more issues. The pthread ones remain.

This was not great to debug.

I wrote that code, and it was not great debugging (proprietary) solaris either. :-)

Is Hurd's fork implemented in glibc?

yelninei · 2026-03-31T09:29:52Z

Is Hurd's fork implemented in glibc?

yes, see glibc/sysdeps/mach/hurd/_Fork.c

the main issue was that things like rmdir and read would crash and finding out about that the version exists and someone has already solved this.
I cant imagine what it would be like first finding out what the problem is in the first place.

yelninei · 2026-03-31T09:34:40Z

One thing for gdc how do these files map to dmd or are these gdc specific?

libphobos/libdruntime/config/common/threadasm.S
libphobos/libdruntime/config/x86/switchcontext.S
threadasm.S: Adding __GNU__ for note.GNU-stack
switchcontext.S: guarding against __MACH__ by additional __APPLE__

yelninei · 2026-03-31T19:40:47Z

I fixed the importc_compare test (so far on the 32bit version only , still need to double check on the 64bit versiob) and made a bit of a messs of the linux/glibc version.

I am not sure about some of the additional types and opague structures that get delcared, should these get moved to a central place even if they are only used at one place?

Sadly some pthread tests still crash

ibuclaw · 2026-03-31T20:22:47Z

BTW, there's an i386 and x86_64 Debian GNU/Hurd machine that recently got added to cfarm. I can do some extra testing, or debug the more painful stuff, but it may some weeks before I get round to it.

ibuclaw · 2026-03-31T20:51:49Z

One thing for gdc how do these files map to dmd or are these gdc specific?

* libphobos/libdruntime/config/common/threadasm.S

* libphobos/libdruntime/config/x86/switchcontext.S

* `threadasm.S`: Adding `__GNU__` for `note.GNU-stack`

* `switchcontext.S`: guarding against `__MACH__` by additional `__APPLE__`

Those are gdc-specific, as context switching itself is done using external asm implementations.

Whereas in dmd, they use their dialect of inline asm (see version AsmX86_Posix / AsmX86_64_Posix)

yelninei · 2026-04-01T10:26:55Z

here's an i386 and x86_64 Debian GNU/Hurd machine that recently got added to cfarm

cool :)

my current bootstrap path is a bit painful.

gdc-11 compiles (for i686) but without support in phobos/druntime it cant compile a later one
It is also missing dlang/phobos#8412

All the changes from https://bugzilla-archive.dlang.org/bugs/22689/ help a lot with decoupling CRuntime_Glibc from linux which are only in later versions.

Support for x86_64-gnu is only officially available since gcc-14 (though a backport of the minimal support from 5f8950b403f6351f125d8281d2e7430a43e7d125 is enough to compile gdc)

I have some patches for gdc-11 and gdc-14 that I currently use to get to dmd, but I have not kept them up to date as maintaining multiple variants of the same changes while it is still quite unstable is a bit to much work for me right now.

I can do some extra testing, or debug the more painful stuff, but it may some weeks before I get round to it

My main problem is that the crash only seems to happen in the druntime/phobos unittest setting and I am failing to reproduce it when compiling/running the module with unittest flags normally (also gdb does not like something with the unittest druntime and ceases to be useful, but this also happens on linux so idk).

ibuclaw · 2026-04-01T15:53:11Z

I have some patches for gdc-11 and gdc-14 that I currently use to get to dmd, but I have not kept them up to date as maintaining multiple variants of the same changes while it is still quite unstable is a bit to much work for me right now.

More than happy to commit them to a development branch under /users/ibuclaw/ in the gcc git repo.

Followup to 90772c4.

yelninei · 2026-04-01T18:48:34Z

Fixed importc_compare on x86_64 which also fixes the testrunner getting killed by the gc suspend signal

yelninei · 2026-04-01T20:01:59Z

More than happy to commit them to a development branch under /users/ibuclaw/ in the gcc git repo.

If you want to take a look they are here: https://codeberg.org/Yelninei/dmd/src/branch/version-1.112/patches
they are definitly not ready and are based on an earlier version of the druntime port.
I have just been focusing on dmd as I can more easily run the unittests to find more issues.

Mostly the druntime change with minor gdc specific adjustments and then connecting things in configure and Makefile and regenerating them

yelninei force-pushed the dmd-hurd branch from e08d353 to 90c7a07 Compare March 27, 2026 16:10

yelninei mentioned this pull request Mar 27, 2026

WIP: phobos: Fixes for GNU/Hurd. dlang/phobos#10980

Draft

yelninei force-pushed the dmd-hurd branch from 90c7a07 to 0843c6b Compare March 27, 2026 17:55