Anatomy of a Binary Executable | Hacker News Reader

Anatomy of a Binary Executable

oswalt.dev

96 pointsWalterSobchak16 comments

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

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...

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).

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?"

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

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

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

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?

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

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.

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

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?

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

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.

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.

Surely just strip the executable/LTO?

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

Reply on news.ycombinator.com