Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jvns.ca

Post reply on HN
Print view View original

41–50 of 93 posts

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

#41

Post by vlovich123 »

cesarb wrote: post #25
kccqzy wrote: post #17

Earlier quoted context omitted.

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

I’m not aware of this problem in MSVC, clang and gcc and those are the most popular afaik.

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

#44

Post by Isamu »

Retr0id wrote: post #3
jstrieb wrote: 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.

Similarly, I'd recommend writing a simple ELF loader. There's a fair bit of implementation complexity in dynamic linking, but if you only support static ELFs then it's straight-forward.

Yes, likewise I wrote a reader that simply tried to parse every bit of a complex ELF binary to report its structure and quickly found myself in poorly documented territory. It’s an education if you want it.

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

#45

Post by secondcoming »

kccqzy wrote: post #17
vlovich123 wrote: post #8

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…

The issue with Meyers Singletons is that every time they're accessed a flag must be checked first. This is bad in hop loops.

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

#46

Post by cesarb »

vlovich123 wrote: post #41
cesarb wrote: post #25

Earlier quoted context omitted.

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

I’m not aware of this problem in MSVC, clang and gcc and those are the most popular afaik.

> I’m not aware of this problem in MSVC

The compiler I was thinking of was indeed MSVC. From a quick web search, it seems that more recent versions of MSVC have changed them to be thread safe by default, so if you can make sure that your code will never be compiled on older MSVC versions (and that nobody will ever use the compiler option which disables the thread-safe initialization), it might be fine to depend on it.

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

#47

Post by [deleted] »

Keyframe wrote: post #30
a-priori wrote: post #9

Earlier quoted context omitted.

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.

[deleted]

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

#48

Post by eichin »

Isamu wrote: post #44
Retr0id wrote: post #3

Earlier quoted context omitted.

Similarly, I'd recommend writing a simple ELF loader. There's a fair bit of implementation complexity in dynamic linking, but if you only support static ELFs then it's straight-forward.

Yes, likewise I wrote a reader that simply tried to parse every bit of a complex ELF binary to report its structure and quickly found myself in poorly documented territory. It’s an education if you want it.

I assume there's a better modern source (assuming for some reason you don't want to reference libbfd &c, but really, you at least want to cross-check with it) but BITD there was an AT&T System V book - I think it was https://books.google.com/books?id=mrImAAAAMAAJ but only at about 70% confidence, it's part of a series and might have been one of the others - that was "arcane but true" for ELF on existing platforms (at the time, which was the mid 1990s, which is why I hope there's a better starting point now...)

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

#49

Post by vitiral »

actionfromafar wrote: post #12

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 may have misunderstood, but I'm pretty sure APE is not a "binary format" per se.

It is a script that can be executed on any system. That script can then LOAD a binary. IIRC the original needed to decode it from base64 before it could be loaded.

So... it's an executable binary loader

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

#50

Post by bruce343434 »

akdas wrote: post #22
jstrieb wrote: 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...

That's an awesome interactive page! Did you write it by hand, or did you use some sort of generator/tool?
Post reply on HN