Porting gdc/dmd to Hurd

yelninei yelninei at tutamail.com
Sat Mar 21 13:31:51 UTC 2026


On Friday, 20 March 2026 at 21:22:22 UTC, HNBas wrote:

>
> The crash you’re seeing on 32-bit smells very much like a 
> calling convention / ABI mismatch for small structs returned by 
> value. Your example (struct Foo1 { char c; }) is exactly the 
> kind of case where different ABIs handle returns differently 
> (register vs. hidden pointer).
>
> A few things you might want to check:
>
> First, compare what gdc emits vs. dmd for that function. Since 
> gdc works, it’s a good reference for the correct ABI on 
> Hurd/i386. Look at the generated assembly for ctest1 and the 
> call site – specifically how the return value is passed back. 
> If gdc uses a hidden sret pointer but dmd expects a register 
> (or vice versa), that would explain the crash.
>
> In dmd, the relevant logic is in the backend where struct 
> return conventions are decided. Files around toir.d, target.d, 
> and the C ABI handling are worth digging into. On x86 32-bit, 
> there’s usually special handling for “small structs” – often ≤ 
> 8 bytes – but that depends on the platform ABI. Since you added 
> Hurd under linux/bsd, it might be inheriting the wrong 
> assumption.
>
> Also worth checking: alignment and packing. A char-only struct 
> might still be treated differently depending on default 
> alignment rules. Try slightly modifying the struct (e.g. add 
> another char or an int) and see if behavior changes – that can 
> help confirm it’s an ABI classification issue.
>
> Another quick sanity check: declare the C function with 
> pragma(mangle) or inspect the symbol to ensure there’s no 
> mismatch there, though this looks more like a return-value 
> issue than name mangling.
>
> Given that 64-bit works, it further points to 32-bit System V 
> i386 ABI quirks. Hurd might follow a slightly different 
> convention than Linux there, so reusing the linux path blindly 
> could be the root cause.
>
> If you narrow down how Hurd expects small structs to be 
> returned, you’ll likely just need to tweak the classification 
> logic in dmd’s backend for that target.

Thanks a lot for the responses.

I think i overlooked/missed a lot of linux cases when I initially 
did this.
I found the i686 linux struct case in target.d and adding hurd to 
that seems to work.
then i also found  lot more unhandled cases for the os.


Almost all non windows dmd tests now pass on i686 (he remaining 
failures seem expected), on x86_64 the test runner gets killed 
with the gc suspend signal after a while, not yet sure whats up 
with that.

there are still some issues with druntime which i think is 
because CRuntime_Glibc is used for linux+glibc in several places.

I also already found a lot of things that are not needed 
anymore/can be simplified significantly as some of my druntime 
changes are initially against gdc-11.


More information about the Digitalmars-d mailing list