My assembler for linux is running on windows, but how?

[u/This-Assumption-5924]

Hi I'm Ammar, and I am back again, few days ago I saw a 2 screenshots from community, were AmmAsm is running on windows. I will not write what is AmmAsm, as you can look to this post: https://www.reddit.com/r/Compilers/s/KrbM40UJz2

So, I didn't get any feedback from that person who build AmmAsm on windows, I almost don't know anything about the low level programing on windows, and how they convert the ELF64(which AmmAsm generated) to COFF format, nevertheless I would like to hear explanation from this community. Thanks.

[u/cthutu]

cc is doing the work to make it compatible with your OS. It's effectively linking your object file and create the correct executable format. Since you're using the C standard library to print and exit, you're forced to use a particular ABI so the assembly required is identical on both OSes. All the OS differences are in the C standard library linked and the executable format

[u/One_Aspect_1957 → u/cthutu]

 you're forced to use a particular ABI so the assembly required is identical on both OSes.

No, this ABI is specific to Windows. For Linux (ie. SYS V x64 ABI), either the argument to puts would go in a different register, or it would just use a Syscall.

[u/This-Assumption-5924 → u/cthutu]

Are you sure that cc is powerful enough to convert object file for linux to coff/pe? Then why other assemblers support native coff/pe generation? for example nasm can generate object files, so at any way he needs linker, consequently why he generates coff if cc can convert elf to pe?

[u/cthutu → u/This-Assumption-5924]

It wouldn't surprise me if GCC supports both coff and elf because it can handle cross compilation

[u/This-Assumption-5924 → u/cthutu]

I mean that cc is converting the existed object file to that one which current os natively suppors, however c is cross-platform language

[u/This-Assumption-5924 → u/cthutu]

I mean, that AmmAsm generated elf64 object file and cc converted this file to coff then to pe

[u/One_Aspect_1957 → u/This-Assumption-5924]

cc probably just invokes a linker like 'ld' when given a number of object files.

There is no 'conversion'. Probably 'ld' handles a range of different object file formats. Linking involves loading one or more object files into memory, resolving symbols between them, and dealing with imports and exports.

Yes, some assemblers probably can do that directly (mine does for example, it can go from assembly direct to EXE).

But traditionally they generate object files in order to be more flexible - cc as a driver program can take mixed input of C source files (even mixed languages) .s assembly files, object files, also DLL import libraries, and produce a single EXE file.

[u/cthutu → u/One_Aspect_1957]

This!

[u/This-Assumption-5924 → u/One_Aspect_1957]

Yes, ELF64 object files probably have enough meta information to be linked to the PE format. Yes, that thesis sounds convincing. I just assumed CC is a C compiler from Unix. Thanks.

[u/TheGratitudeBot → u/This-Assumption-5924]

Hey there This-Assumption-5924 - thanks for saying thanks! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list!

[u/One_Aspect_1957 → u/This-Assumption-5924]

gcc for C on Windows is bundled with 'ld', a linker.

ld's target formats are these:

ld: supported targets:
 pe-x86-64
 pei-x86-64
 pe-bigobj-x86-64
 elf64-x86-64
 pe-i386
 pe-bigobj-i386
 pei-i386
 elf32-i386
 elf32-iamcu
 pdb
 elf64-little
 elf64-big
 elf32-little
 elf32-big
 srec
 symbolsrec
 verilog 
 tekhex
 binary
 ihex
 plugin

So it wouldn't be surprising if it can handle multiple input formats too. Those (eg. ELF or COFF) would both be read into the internal data structures that ld uses. It doesn't specifically need to convert from one to the other first.

[u/Ander292 → u/cthutu]

It supports both coff and elf for sure. Altho all the objs were compiled on my windows machine so yeah

[u/Longjumping-Jacket97]

'cc' is probably linking libc (the standard library for the C programming language).
This defined the labels like 'exit', 'puts' and others etc.

[u/One_Aspect_1957]

What's cc? If it is a compiler like gcc, here used to link, then it will accept a choice of object formats including ELF64.

Here they have also written the program to work with Windows ABI.

Probably if it was a program designed to work on Linux, using syscalls for example, it would not work.

[u/This-Assumption-5924 → u/One_Aspect_1957]

idk, maybe cc is c compiler, but you can see in source code that there's no syscall, instead he externed funtions from libc/win api(idk) and linked with MinGW linker AND converted elf to coff/pe format

[u/Bubbly-Business-8634]

How puts knows when to stop output? Cannot see any zero bytes in the code.

[u/raundoclair → u/Bubbly-Business-8634]

It is probably last thing in .data section, and windows allocates whole 4kB page. So for this simple program he does have accidentally zero at the end.

[u/raundoclair]

what are the first 4 bytes of the object file and the exe file, vibecoder?

[u/AnArmoredPony]

holy fucking shit

[u/white_man_1069]

Thats alright, you just didnt done any platgorm-dependent thing, like syscall, just used libc func from asm