flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > ELF64 object sizes

Author
Thread Post new topic Reply to topic
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
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!
Post 07 Jul 2015, 05:01
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
What is your question? Is the file too long? Too short? Missing something? Something extra? Bloated with empty space? Not enough alignment?
Post 07 Jul 2015, 05:49
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
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.
Post 07 Jul 2015, 05:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
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.
Post 07 Jul 2015, 06:03
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
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 Smile
Post 07 Jul 2015, 06:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
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.
Post 07 Jul 2015, 06:13
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
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!
Post 08 Jul 2015, 00:50
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.