Windows Support

[n1ght-hunter]

Hey i don't have much experience with linkers but know rust pretty well. I was wondering if you had a mental or physical list of what is required to get windows support. even if its not quite as good as linux support. i would be interested in starting work on it.
i did see windows is on the roadmap but pretty far down

[davidlattimore]

Supporting Windows (or Mac) is certainly a very large undertaking. I've heard that in LLD, the ELF, COFF/PE and Mach-O linkers are basically 3 separate linkers that share a few utilities, but are otherwise separate (but built together into one binary). I'm cautiously optimistic that it might be possible to share more than a few utilities, but I'm also pretty ignorant of COFF/PE and Mach-O, having never worked with either.

Parsing of input objects is something that we fortunately don't need to implement, since the object crate, which we use for parsing ELF files has us covered there.

The first thing to do would be to get a trivial program to link. This might be a test like trivial.c. On Linux, this test just calls the exit syscall. Getting a program that can just exit requires a bit of work. Unfortunately doing exactly the same kind of test on Windows won't work because Windows doesn't have a stable syscall interface, which as far as I know means that all binaries need to be dynamically linked. Dynamic linking raises the bar a bit for getting something working. One possibility is to have a test that produces a DLL rather than an executable. Then the trivial test would be to produce a DLL that just defines a single function that returns 42. The test framework can verify this by loading the DLL and calling the function.

Wild development is helped a lot by the use of linker-diff, which allows us to compare what we're producing with what other linkers produce. It'd be good to add support to linker-diff for working with PE binaries. Doing this, while a bit of an up-front investment, makes subsequent debugging a lot easier. Fortunately a bunch of the heavy lifting here is done by the object crate parsing the input files.

Probably what I'd do would be to build out support in linker-diff and support in wild in parallel. e.g. get Wild to write the file header and section tables, then get linker-diff to check those bits. It should be possible to make a bunch of progress in that way before even a trivial executable or DLL can actually be executed.

There would be lots of refactoring needed to wild as differences between the formats are dealt with. Where there are bits of code that are partially the same and partially different, we can hopefully put the different parts behind a trait in a similar way to what we've done with the Arch trait, which abstracts x86-64, aarch64 and soon riscv64.

I'd say the first thing to do would be to familiarise yourself with the PE format.

You're also welcome to book time in my calendar to discuss this in person.

[davidlattimore]

Great! At some point, I'd like to introduce a trait and move as much of the ELF-specific code as possible behind the trait. That should in theory make it possible for us to share as much code as possible between the ELF linker and the PE linker.

[n1ght-hunter]

awesome. btw did i have any thoughts about splitting out the code into more crates? i was thinking about moving arg parsing to a separate crate on my branch. personally i like relatively small crates

[davidlattimore]

I tend to treat crates as the unit of reuse. So if part of the codebase is useful outside of the linker, then I'd move that out to a separate crate. I'm not sure that I see a particular use-case for linker argument parsing outside of the linker. There are downsides to moving code to separate crates. The main one would be that all the fields on Args would need to be made public, which would mean that we wouldn't get dead-code warnings if a field is unused by the linker.

[mati865]

On Windows, there are two "families" of linkers: link.exe and ld.bfd.
While ld.bfd shares a lot of arguments between Linux and Windows version (some are Linux specific and some are Windows specific), linke.exe is a totally different thing. It'd need its own Args structure and some modifications to argument parsing because of the horrible choice of using slashes for arguments, with a single dash as a fallback.

ld.lld on Windows is mostly a wrapper around lld-link that translates ld.lld style args to link.exe args and tweaks the defaults.

[n1ght-hunter]

ya im working on parsing link.exe style args atm.

in terms of crates yes its true u lose dead code checks. i just like the separation of concerns. i.e args is fully separate and it doesn't matter what i do outside of args crate it doesn't change. totally valid to not want to though