Part of my releasing the C/C++ integrations examples shed light on something I have been meaning to ask about regarding fasm's output.

Specifically, format ELF64.

When I compile my contrived "include_everything" example, fasm produces an ht.o file that is 810086 bytes in length with the current version of my library (1.12 at the time of this writing).

When I then use gcc to link said object file with a simple do-basically-nothing C main, the resultant file is 668608 bytes in length, and of course includes every single function that was in the original ht.o file.

Is fasm producing output that gnu-ld deems unnecessary? With smaller projects, the difference is still there just not as pronounced as this one.

The examples/hello_world_c1 directory of my library (https://2ton.com.au/HeavyThing-1.12.tar.gz) contains the "glaring" example, and compilation instructions can be seen on the example page I did up for it at https://2ton.com.au/rants_and_musings/gcc_integration.html.

Also note: when fasm produces executable output format, the same "issue" can be seen.

Am I missing something obvious here? Executing nm on both the final exe and the ht.o fasm output produce all of the same function definitions...

Any enlightenment would be most appreciated.

Cheers!

What is your question? Is the file too long? Too short? Missing something? Something extra? Bloated with empty space? Not enough alignment?

Sorry, haha should have been more clear:

fasm -m 262144 ht.asm == ~810000 byte file
gcc -o hello hello.c ht.o == ~681000 byte file.

Fasm's output is bloated, despite the same functions existing in both ELF objects.

I would expect an object file to have slightly more detail than the executable file needs. Does gcc include all the optional debug information in the executable, or does it strip that? There are many ways an ELF file can be formed, and with the sections and other things being combined it would save some space.

Perhaps you can dump the output with an ELF viewer and see exactly what is the difference.

Actually, we know that fasm does not produce any debug information, and it is not the gcc output that is bloated, it is fast's.

So, if you do an "nm" (or objdump -dx, etc) listing on both fast's output ht.o and the final exe from gcc (which includes ALL of ht.o as it must), they both contain the same functions, and if anything gcc's includes more, hence my question in the first place.

Similarly, if I get fasm to produce the final exe itself, without using gnu LD or gcc as I have done in these examples, once again fasm's final exe size is similarly bloated as in my example and this is ultimately what my question is about.

When gcc/ld goes and parses fasm's output, it strips a not-insignificant portion of the resultant binary (which begs the question of what fasm IS producing that binutils happily removes without affecting anything else).

I will do some more digging and see if I can answer my own question

Start with a small file first would be my suggestion. Just one or two functions. No need to lose the forest amongst all the trees.

It appears to be the relocation table (elf: HAS_RELOC), a fairly sizable table in my case that follows the data segment, and before the symbol table itself.

Interesting indeed and now that I understand what it is, makes perfect sense. haha, fun figuring it out properly anyway.

Cheers!