Support for other platforms/architectures?

[heavyrain266]

Hey, do you have any plans for Linux on ARM or Windows support? macOS in this case feels useless after Apple introduced "ld_prime" as fast threaded linker for their platforms. Always happy to help.

Happy to see that Wild comes as a library, Mold's author refused to expose it in such form! in particular, I'm interested in testing Wild on the build farm that works on Ampere Altra Max (aarc64) mainly used to build Android and games from friendly studios. And in the future also to link GPU firmware that runs on RISC-V co-processor but the architecture itself varies between implementations... (missing/modified/replaced or added instructions)

Unrelated, but noticed that the source code is rather hard to read and doesn't play well with screen readers (missing new lines etc).

[davidlattimore]

Hi @heavyrain266! I'd definitely like to expand support to other platforms and architectures. There's still known bugs and missing features with what's currently there, so that's where I'm mostly focusing at the moment.

Adding support for ARM is likely to be considerably easier than adding support for Windows. I think all the CPU-specific code is in relaxation.rs. So it'd hopefully be a matter of writing a new implementation of that for the new CPU architecture. For the first new architecture, there'd also be some work to allow switching between architectures. Oh, and there's a small number of tests that use assembly. It may be possible to rewrite them in C, or maybe they're not needed anymore and could just be deleted.

Windows support would be considerably more work, since it uses a whole different object format. It's something I'd like to do eventually though. There's lots of assumptions about elf in lots of places. So probably I'll need to define a trait, make various bits of code generic over that trait, then wherever there's elf-specific stuff, move it into an implementation of the trait.

The interface that Wild exposes as a library is something that I'd expect to evolve once someone actually wants to use it as a library. At the moment, it's pretty much just the command-line interface, but as a library.

If there's things I can change to make the code easier to read with a screen reader, I'd definitely like to try to do what I can. When you say missing new lines, do you mean that I should try to leave the occasional line blank so as to group bits of code more within functions?

[heavyrain266]

Hey, thanks for such quick response! I'm happy to help. I'm not using Linux too often on my workstation (more often on servers and various boards etc), which is why I was wondering if you plan support for Windows.

Such linker is something I wanted to do myself long time ago but it's hard to find any useful resources on how linkers are implemented other than source code. One thing I did in the past was SPIR-V shader linker for mobile/automotive GPUs.

When you say missing new lines, do you mean that I should try to leave the occasional line blank so as to group bits of code more within functions?

No, not really. I actually meant empty lines between variable groups, variables and loops or conditionals etc. I do pair programming with blind person, and to him it was hard to understand without hard stops in the code.

[davidlattimore]

Great that you'd like to help! Are you wanting to work on adding Windows support, or start with a few easier things first? If you'd like to discuss via a video call, feel free to book some time in my calendar. It's linked from my github profile.

I'll try to make a little more use of vertical whitespace when I'm coding. I suspect the biggest things I could do to aid readability are to look for opportunities to extract out functions. Some functions have grown a little too large. Although it can sometimes be hard to extract out functions without either ending up with functions that take lots of arguments, or structs with lifetime parameters - but I'm sure there's more than can be done even without either of those.

[heavyrain266]

Hm, I guess will read more on ELF format first, and see how it goes. Also for now will look into testing linker against DreamWorks' MoonRay and Odin language compiler on Linux, both are quite big C++ codebases.

[davidlattimore]

Cool. It's worth noting that the linker hasn't been extensively tested on C++ codebases - I've mostly tested on Rust code. Rust code generally doesn't mess with the flags passed to the Rust compiler, however C++ projects often use very different flags. Those differences in flags can make a big difference to the linker. i.e. failures are more likely than not.

[heavyrain266]

there is also rustix to which many projects migrated (works on Windows)

[davidlattimore]

The use of pipe is related to the forking feature, which, not surprisingly uses fork, which as far as I know isn't available on Windows. I've just put up a PR - #216 - to make that an optional feature. Hopefully that helps with getting Wild to compile on Windows. If you're interesting in porting Wild to be able to produce Windows executables, I'd be very interested to hear more about your plans.

[mati865]

I can look into making it compile on Windows in about a month. It would still target Linux, however.

Producing PE/COFF binaries is a tremendously bigger task, as you cannot use ELF on Windows. Mold doesn't support it at all, the PE/COFF backend of LLD is basically a different linker compared to its ELF backend, and PE/COFF in ld.bfd still hasn't reached the point of fully working.
Don't get me wrong, I'd love to see a second properly working linker (alongside LLD) for Windows, but realistically, there are good reasons why there aren't many linkers for this platform.

[mati865]

With https://github.com/mati865/wild/tree/push-wxxonomllnql running cargo t -- --skip 'aarch64::test_align_up' --skip 'integration_test::' passes with x86_64-pc-windows-gnu and x86_64-pc-windows-gnullvm hosts.

aarch64::test_align_up requires a disassembler that can read ELF, integration_test is expected because it needs a toolchain targeting Linux.

[n1ght-hunter]

The use of pipe is related to the forking feature, which, not surprisingly uses fork, which as far as I know isn't available on Windows. I've just put up a PR - #216 - to make that an optional feature. Hopefully that helps with getting Wild to compile on Windows. If you're interesting in porting Wild to be able to produce Windows executables, I'd be very interested to hear more about your plans.

@davidlattimore just fyi fork is kinda available in the form of NTCreateProcess an undocumented windows api.
working version off fork on windows 11 here
https://github.com/n1ght-hunter/wild/blob/dev/window-support/windows/wlibwild/src/subprocess.rs