Live data from Hacker News

How is a binary executable organized? Let's explore it (2014)

jvns.ca

21–30 of 93 posts

Re: How is a binary executable organized? Let's explore it (2014)

#21
post #9
post #7

Earlier quoted context omitted.

to extend on it, _start is where .text begins and address of that is set by linker

The entry point can be anywhere in the .text section, and often won't be at the beginning of the section.

Technically it doesn't even need to be in the .text section, it could be anywhere in the address space. You'll get a segfault if it's not somewhere executable though (assuming you're on a system with an appropriately configured MMU)

Re: How is a binary executable organized? Let's explore it (2014)

#22
post #2

As I've said in other threads https://news.ycombinator.com/item?id=38847750#38862450 , I highly recommend writing an ELF by hand at least once. It's a great exercise to understand the basic parts of an executable. It's also helpful if you want to go the opposite direction of this article - bottom-up instead of top-down. Lots of other great discussion in various threads on that other HN post.

Writing an ELF file by hand is something I did recently: https://github.com/avik-das/garlic/blob/master/recursive/elf...

To explain the format to myself and others, I also created an interactive visualization for the bytes in the file. It helps me to click on a byte, see an explanation for it and see related bytes elsewhere in the file highlighted. https://scratchpad.avikdas.com/elf-explanation/elf-explanati...

Re: How is a binary executable organized? Let's explore it (2014)

#24
post #16

> Executables aren’t magic. Nothing in a computer is magic. It was all designed by humans, every single one of which was once a clueless noob. No one is born understanding this stuff.

> This does a bunch of Very Important Things that I don’t understand very well, including calling main. So I won’t explain them.

Honestly, this line was the best in the whole article. It felt like at that moment I knew the person talking to me wasn't trying to prove that they were some sage (personally guilty here) but instead of was someone who wanted to show me something cool that we could both enjoy.

Wonderful write up.

Re: How is a binary executable organized? Let's explore it (2014)

#25
post #17

Earlier quoted context omitted.

> Things that I don’t understand very well, including calling main. So I won’t explain them. It depends on the language runtime, but a common task will be initializing global non-0 statics. For languages like Rust/C/C++ you can also inject variables to be initialized via linker flags. Before start if the program is dynamically linked then I believe the linker runtime is run to resolve the links and then transfer cont…

The style guide at both my previous and current employers explicitly forbids having global non-0 statics for this exact reason: code that runs before main() is very unusual. Many assumptions do not hold. A far better way is to use function-local statics. A static variable inside a function is initialized when execution reaches that point when the function is being called. Furthermore, such initialization is thread sa…

> Furthermore, such initialization is thread safe so that one initialization happens despite multiple concurrent calls of the function.

IIRC, there are some popular compilers in which initialization of static variables inside functions is not thread safe (even though AFAIK the C++ standard said they should be).

Re: How is a binary executable organized? Let's explore it (2014)

#26
post #18

Not a criticism, not even a nit-pick, but a reflection "(binaries are kind of the definition of platform-specific, so this is all platform-specific) (this is true!) When "Actually Portable Executable" took the (geek) proved that the same binary could run on a bunch of platforms, that was a surreal moment I still haven't mentally recovered from. Here we spent decades trying to solve the cross-platform problem, in so m…

I personally am not convinced that portable binaries are a net positive. I believe in the era of fast computers that source distribution and local compilation is superior to binary distribution. Unfortunately, much of the software we rely on is so large, and compilers so relatively slow, that binary distribution is something of a necessary evil. I'd rather see more effort towards simpler software components (that nat…

You can have both. APE are generally faster and smaller.

Fat APEs (aarch64 + x86_64) are larger, but interesting in their own way.

Re: How is a binary executable organized? Let's explore it (2014)

#27
I started my blog in 2012, when I shifted my academic career from Mathematics to Computer Science. This topic was literally the first thing that I studied:

https://heinrichhartmann.com/archive/Dissecting-Hello-World....

Never regretted going down this deep rabbit hole. IIRC, Julia also has a math background. Maybe it's the desire for bottom-up reasoning that leads math folks towards experiments like this. Great to see her making this approachable for a large audience.

Re: How is a binary executable organized? Let's explore it (2014)

#28
post #16

> Executables aren’t magic. Nothing in a computer is magic. It was all designed by humans, every single one of which was once a clueless noob. No one is born understanding this stuff.

"It is no exaggeration to regard this as the most fundamental idea in programming: The evaluator, which determines the meaning of expressions on a piece of paper, is just another piece of paper." --SICP

Re: How is a binary executable organized? Let's explore it (2014)

#29
post #16

> Executables aren’t magic. Nothing in a computer is magic. It was all designed by humans, every single one of which was once a clueless noob. No one is born understanding this stuff.

> Nothing in a computer is magic.

I think that’s covered by the text, in the sentence right after that one (emphasis mine):

> ELF is a file format like any other!

Re: How is a binary executable organized? Let's explore it (2014)

#30
post #9
post #7

Earlier quoted context omitted.

to extend on it, _start is where .text begins and address of that is set by linker

The entry point can be anywhere in the .text section, and often won't be at the beginning of the section.

yes and then you'll have a bad time, but at the same time per convention _start is where .text begins. You can see where it starts with readelf --file-header and look at Entry point address field. You can change it, yes.
Post reply on HN