Question regarding COFF .o CRT files

[gwald]

I'm wanting to get this debugger/analyzer: https://whitebox.systems/ (readme/issues: https://github.com/WhiteBox-Systems/whitebox/) But not sure if it works on windows with this port of GCC. It uses clang, it's works with GCC on linux, so I assumed GCC on windows would also work, I sent the dev this repo via his discord and he got back me with:

I downloaded this to have a play around, although I'm not very familiar with non-MSVC toolchains on Windows, so take it for what it's worth:

    Getting the include headers to work seems straightforward:

// Compiler Preferences
-nostdinc
-isystem C:\bin\w64devkit\x86_64-w64-mingw32\include

    Loading the .o CRT files is more of an issue: the released version of WhiteBox assumes ELF objects & those are COFF...

There may be a way round it but I ran out of time for exploration

I get ELF and COFF are binary executable formats, so I'm pretty sure I'm S out of luck, but thought I would check with you first.

[skeeto]

Your guess is correct: This toolchain produces and consumes COFF objects, and ELF is mostly unsupported. In theory, objcopy can convert in place:

$ objcopy -O elf64-x86-64 example.o

The result is ELF, though I'm not confident the conversion is correct, and I bet it's unlikely to work for you. If I attempt to link it with ld, it chokes on relocations. If I convert back to COFF (pe-x86-64), it still doesn't link, i.e. doesn't survive a round trip. Since objcopy doesn't understand archives, to convert runtime objects you'd need to unpack, convert, and repack each .a library.

The WhiteBox situation seems odd: Its primary supported system is Windows (Linux support came later), but it's exclusively ELF. I guess they just like ELF, and Clang doesn't have strong opinions about object formats.

[gwald]

Cool :) Thank you for the explanation

[azmr]

Hey, WhiteBox dev here.

Thanks for the info on this.

I agree that the file format situation with WhiteBox is a bit wacky 😄 It's not ideological though: it was a quirk of development given what was easiest to JIT compile with clang. Object file support in general has to a large extent been a second class citizen, just based on the way WhiteBox has typically been used... Adding COFF object support has been on the TODO list for a while, but there have always been things ahead of it. Seeing that not having it basically cuts off using it this toolchain has bumped it up the list somewhat 😉

[Peter0x44]

I suspect binutils accepting elf in the objcopy context is a bug/oversight of some sort. x86_64-w64-mingw32-windres: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin windres lists all of these targets, but none of the "elf" ones actually make anything, they just give various assorted errors.

$ x86_64-w64-mingw32-windres --target="elf64-x86-64" -i test.rc -o test.o
x86_64-w64-mingw32-windres: can't get BFD_RELOC_RVA relocation type: cause of error unknown
$ x86_64-w64-mingw32-windres --target="elf32-i386" -i test.rc -o test.o
x86_64-w64-mingw32-windres: test.o: unsupported relocation type: 0x3f
$ x86_64-w64-mingw32-windres --target="elf32-iamcu" -i test.rc -o test.o
x86_64-w64-mingw32-windres: bfd_set_arch_mach(i386): cause of error unknown

I don't see how converting to/from elf would even have a practical use, it's not like any OS using elf is using the windows calling conventions (I'm pretty sure...).

So it does make sense that it's "broken", I sincerely doubt it ever was supported to begin with.

[Peter0x44]

Also, regarding whitebox, does this mean MSVC supports elf? Or what's the deal with that.

[azmr]

Clang can compile ELF objects on Windows with clang -target x86_64-pc-windows-elf ... I haven't tried using MSVC to build/run them. The objects are only used as symbol sources within the context of WhiteBox's JIT.

[skeeto]

Thanks for chiming in, @azmr!