Hacker News new | past | comments | ask | show | jobs | submit login

ELF(COFF) should now be only an assembler output format on modern large hardware architecture.

On modern large hardware architecture, for executable files/dynamic libraries, ELF(PE[+]) has overkill complexity.

I am personnally using a executable file format of my own I do wrap into an "ELF capsule" on linux kernel. With position independent code, you kind of only need memory mapped segments (which dynamic libraries are in this very format). I have two very simple partial linkers I wrote in plain and simple C, one for risc-v assembly, one for x86_64 assembly, which allow me to link into such executable file some simple ELF object files (from binutils GAS).

There is no more centralized "ELF loader".

Of course, there are tradeoffs, 1 billion times worth it in regards of the accute simplicity of the format.

(I even have a little vm which allows me to interpret simple risc-v binaries on x86_64).






You're giving up a lot if you stop using a format that supports multiple mapping, relro, dynamic relocations, ...

This is where the "scam" from those excessively complex formats is: I, pertinently, do not give up a lot since I get the job done... but on the other side, I gain the removal of tons and tons of complexity, and nullify significant developer/vendor lock-in at the same time.

A good analogy to "feel" that, it is a bit like "json vs xml" but for executable binary formats.

But, I keep in mind, those formats (excrutiatingly simple) can work only on modern hardware architectures.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: