“With December upon us, rife with rumors of labor disputes (again!) at the North Pole, it seems about time to talk about the ELF standard. ELF (ELF is an acronym for Executable and Linking Format) is a standard for object modules, libraries, executables, and core files. Many UNIX and UNIX-like systems use ELF, and the ELF standard has contributed substantially to the development of compiler toolchains and debugging tools for a variety of systems.”
Usually IBM articles bore the crap out of me, but this one was actually good reading. I finally know a bit about what ELF is about.
Agreed!
I particularly enjoyed the links at the bottom. Particularly the 45 kbyte executable tutorial [1]. Sure, it’s not very useful for practical purposes, but it does help explain what’s going on under that big old gcc hood.
[1] http://www.cs.dartmouth.edu/~cs38/local/teensy.html
Particularly the 45 kbyte executable tutorial
You mean 45 bytes 🙂
You never read the one about Wearable Computing? It was two pages of this guy talking about cyberpunk fiction and then some info about some hobbiests who put some embedded comps in jackets and such.
Far more illuminating than downloading the ELF specs and reading them!
So what are the strengths of ELF compared to other executable formats and what are the weaknesses?
Are there things you just cant do with ELF that you can do with other executable formats or are they all much the same?
What are the plans for extending ELF?
ELF is crap. It fails to operate in the basic intuitive manner you’d expect of such a format. It’s biggest crime is to try and replicate the semantics of static linking in a dynamic world, leading to serious performance problems, over complexity and introduction of obscure bugs into programs that hardly anybody can diagnose.
It’s also a pain in the ass to read thanks to its maze of interlocking tables, sections, segments, headers and god knows what else.
That said, PE (Windows) isn’t exactly lightyears better. And Mach-O (OS X) is arguably even worse than ELF. It blows my mind that after 25 years nobody has yet come up with an executable binary format that doesn’t suck!
-mike hearn
I’ll give you the complexity and the obscurity, but could you elaborate on the performance problems? You’re talking about the linking overhead at startup (and perhaps PLT indirections) are you not?
Yes, I’m talking about the need for a linear search of the entire symbol scope for every lookup (in the absence of Sun style extensions which allow for direct linking). The only reason for this is to emulate the static linking days, and it’s a very bad reason.
RTF Man page
void *sym = dlsym(NULL,”symbol”);
You sound as if your are intimately familiar with all of the formats. Perhaps you can write this format that “doesn’t suck” with your vast knowledge.
I could, and what OS would use it? Binary formats are sufficiently low level that few programmers have to interact with them directly, and the work Michael Meeks is doing with binutils and glibc should (if the relevant people stop ignoring him) fix some of the worst bugs of the format. At that point it doesn’t really matter that ELF is convoluted and has to be extended to be sane, because it’ll get out of the way and stop making people think about it.
*I* don’t claim being familiar with all the formats but I’m quite surprised that objects files used C strings to stores symbols which means that upon linking the string comparison is quite slow.
A length+string type would seem much more faster, no?
First, it allows fast rejection because if two different strings don’t have the same length they cannot be identical, then it allows looking at strings end first: usually strings beginnings are identical due to the way the symbols are built ie module-class-function-variable.
Does someone have an explanation why this was done, the file increase of two bytes per symbol doesn’t seem that high..
The symbols’ matching is an important part of the linking time, if I remember the figures given when someone investigated why KDE apps started slowly.
It blows my mind that after 25 years nobody has yet come up with an executable binary format that doesn’t suck!
You have a fantasy about what you think the “perfect” format should be without considering real-world issues.
FTFA:
In the 1990s, a group of vendors got together and released a formal version of the ELF standard for public use, hoping that everyone would use this standard format and benefit from it. For the most part, everyone has.
…
The committee announced availability of its standards in March of 1993; committee members included compiler developers (such as Watcom and Borland), CPU vendors (such as IBM and Intel®), and OS vendors (such as IBM and Microsoft). (Microsoft’s PE-COFF was another standard they documented.) In 1995, the committee had more members and released the ELF 1.2 specification; the committee disbanded shortly thereafter, having done what they wanted to do.
In other words, people who actually USE file formats and write applications and compilers got together and hammered out what they NEEDED a format to support for real-world usefulness. Sorry if it doesn’t meet your unrealistic expectations.
Well as long as you SAY so. I hear ELFs kill kittens in the night as well.
I thought ELF stood for Extensible Linker Format, or at least it did when I was working at Bell Labs in the late 1980’s.
I think that any OS is free to optimize the format by adding dedicated sections for, eg, speeding up the symbol look-up. It can do that either by extending the static linker, or by managing in-RAM caches.
However the guys in the ELF comittee probably wanted to give freedom to implementors, hence they didn’t focus at all on optimization issues.
The same applies probably to the PLT indirection too. Personnaly I can’t think of any other portable way (architecture-wise) of providing dynamic shareable binary code. So, if optimizations are possible, they are probably architecture specific, and OS-specific as well. Indeed, if an OS restricts its level of service and dynamism wrt UNIX (eg by removing dlopen()), things get simpler.
Eric Dujardin