💾 Archived View for dioskouroi.xyz › thread › 24994522 captured on 2020-11-07 at 00:47:12. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Anatomy of a Binary Executable

Author: WalterSobchak

Score: 94

Comments: 16

Date: 2020-11-05 00:26:46

Web Link

________________________________________________________________________________

woodruffw wrote at 2020-11-05 05:31:17:

This is a nice summary! Kudos.

Some nitpicks from someone who spends most of their professional day looking at machine code:

"Execution section" is a weird phrase -- we'd normally talk about a specific section containing machine code (e.g., the `.text` section), or a collection of executable _segments_ (i.e., regions that will be mapped with executable permissions at program load time).
It's a stretch to call x86 "hardware independent." It has two major vendors (with a few peripheral ones), and is both complex and deeply generational (in terms of features being frequently added) as far as ISAs go. JVM bytecode is closer to hardware independent; LLVM IR _can_ be hardware independent but frequently isn't in the real world.
Rust and LLVM might not have done this because you ran a debug build, but I actually would have expected your `sum` function to have no stack allocations at all -- it's both small enough to fit within the red zone[1] and is also trivially promotable to registers. Sure enough, with `opt-level=1` or above, the compiler gets very clever and actually uses a `lea` to perform the sum[2].

[1]:

https://en.wikipedia.org/wiki/Red_zone_(computing)

[2]:

https://rust.godbolt.org/z/dojnvs

userbinator wrote at 2020-11-05 04:07:43:

As someone who started programming in DOS, where binaries are usually much smaller, it's always annoyed me a bit that compilers and linkers don't seem to even make the slightest effort at not putting unnecessary bytes into their outputs, with things like:

_Used for explicitly requesting that the stack is executable (note in the output above, this bit is not set)_

...and 42(!) section headers in a binary definitely seems overkill; a normal Windows PE file has less than half a dozen.

Nonetheless, the ELF format can be trimmed down considerably:

https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht...

ynik wrote at 2020-11-05 08:09:20:

Windows PE files have, in addition to the section table, also the "Data directories" which are a whole bunch of pointers into some of the sections. Some of these serve the same purposes as some ELF sections. So it's a bit unfair not to include them in the count when comparing the systems.

And of course many of those 42 ELF sections are for debug info. On Windows debug information is usually stored in a separate file (.pdb), which also makes the comparison unfair. I have to admit though that Windows' handling of debug symbols is much more useful (especially when you have a symbol server).

bregma wrote at 2020-11-05 12:38:36:

That link demonstrates a file that can be loaded by the x86 Linux kernel can be trimmed down. It ends up no longer an ELF file, but the x86 Linux kernel will load it as if it is one.

The whole article confuses the question of "what will a 32-bit x86 Linux kernel load?" with "what is the smallest ELF file I can make?"

unnouinceput wrote at 2020-11-05 02:35:24:

Title should be "Anatomy of a Linux Binary Executable". Other than that it's a good starting article for who ever is interested to see what's under the hood at lowest level possible

rob74 wrote at 2020-11-05 09:28:08:

Or, even more specifically, "Anatomy of a Linux Binary Executable Generated by the Rust Compiler"

disown wrote at 2020-11-05 02:31:58:

Interesting article. The x86-64 ABI Docs link is broken though.

carrolldunham wrote at 2020-11-05 05:13:20:

Is it unreasonable of me to lose all interest in linux development upon seeing a command line exe to add two numbers is 3.1MB, and not just that but have it's being 3.1MB treated casually as just interesting/cute by a linux dev?

eatingCake wrote at 2020-11-05 06:12:43:

It may be worthwhile to point out that the example is built in debug mode, and also Rust is including the whole standard library in the output. Re-configuring some low hanging fruit [1] reduces the binary size on my test machine to 27K. This is still not small, granted.

[1]

https://github.com/johnthagen/min-sized-rust

executesorder66 wrote at 2020-11-05 06:51:41:

What does this have to do with Linux? If he compiled it on windows it would have been a similar size.

As eatingCake already mentioned this is not optimized for release, but for debugging.

Joker_vD wrote at 2020-11-05 07:32:40:

Almost empty .NET executables are 8 KB. Almost empty MSVC executables are less than 64 KB.

executesorder66 wrote at 2020-11-05 07:49:50:

I'm asking what this has to do with Linux.

This is not a discussion of rust vs .NET. this is a discussion of Linux vs windows.

So I don't see how your comment is at all relevant.

If you compile the exact same rust code in the post on a windows machine, using cargo like in the post, then is the resulting windows executable file size really any different compared to the linux one?

userbinator wrote at 2020-11-05 14:45:09:

MSVC somehow wants to link statically by default, but if you use dynamic linking an empty executable shrinks to around 4k.

a1369209993 wrote at 2020-11-05 17:49:43:

A little, because your observation evidences bad default configuration of one particular compiler _targeting_ linux rather than a inherent property of linux develoment in general. To be fair, this is a recurring problem with modern mainstream compilers (linux and otherwise), though.

See

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

for a example of going very far (maybe even too far, once they start overlapping things, but YMMV) in the opposite direction.

bregma wrote at 2020-11-05 12:55:39:

It's possible to write bloated software for any operating system or execution environment. It's not considered particularly interesting for very many Linux devs.

If you don't understand how debug information works, or where the bits that provide your language, library, and OS runtime live, then you might well be surprised that they exist at all. It is, after all, sufficiently advanced technology.

mhh__ wrote at 2020-11-05 08:10:35:

Surely just strip the executable/LTO?

Where else is there to go anyway, Forth running on a microcontroller?