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