Off topic — does anyone know more about what happened to the Kestrel project? It sounds from the note in the archived GitHub project[0] like the maintainer shut it down because a company released a similar product with the same name. Seems odd (and sad).
On ELF, Part 2 (2018)
11–20 of 36 posts
Re: On ELF, Part 2 (2018)
#12[deleted]
Re: On ELF, Part 2 (2018)
#13Just submitting part 2 of this as I stumbled across it after having played around with write ELF files by hand. Never knew about the Hunk format and I think the author makes some interesting points.
Might you have any interesting resources you could share regarding how you learned to write ELF files by hand?
Re: On ELF, Part 2 (2018)
#14Off topic — does anyone know more about what happened to the Kestrel project? It sounds from the note in the archived GitHub project[0] like the maintainer shut it down because a company released a similar product with the same name. Seems odd (and sad). [0] https://github.com/KestrelComputer/kestrel
He has a post with some details here:
https://kestrelcomputer.github.io/kestrel/2017/03/07/kestrel...
Re: On ELF, Part 2 (2018)
#15This is all well and good, but in reality everyone is using all the rich features of ELF -- dynamic linking obviously, but also symbol versioning, constructors, symbol interposition (probably the worst one for performance), symbol visibility, preload, etc. The question is how to make it fast in the common case, and actually the Linux and glibc authors are doing a pretty good job here.
I have looked quite closely into glibc in the past and there are great many things that could be improved and not using some of the fancy ELf features is probably one of them. For example symbol versioning doesn't appear to have a good cost/benefit balance.
Symbol versioning is the feature which has kept libc at major ABI version 6 for all these years. The libc5 -> libc6 major version bump gave users trouble for many years afterwards.
Re: On ELF, Part 2 (2018)
#16> I show how ELF-like features can be safely retrofitted onto executable formats contemporary with ELF’s debut.
I am surprised at the naïvité of the author on this question as from his photo he probably lived through this transition in real time. The statement ignores the whole point, sort of liking saying “all modern computers are basically Turing machines.” True, but not insightful.
It was no surprise to anyone at the time that various other required features could be jammed into other approaches (well, not a.out which is too simple) and often were in ad hoc and incompatible ways. In fact I designed the bfd library specifically with this in mind, to try to give some generality to object file generation and manipulation.
ELF was designed by committee, but it is not a camel. It addresses a number of complex issues in a standard and extensible way. Issues that didn’t arise on a time shared PDP-11 in the 1970s.
Re: On ELF, Part 2 (2018)
#17I worked with a.out on early unixes and elf on later ones - not addressed here is the main reason for switching: ELF allowed you manage pages contiguously on disk so that they could be paged in directly (stuff can be page aligned within the file at it's natural offsets), while a.out was designed for swapped kernels where you would just read() data into a text section, address 0 might be 32 bytes from the start of a f…
What’s the advantage of that? Would the kernel just load the entire file into contiguous memory and set up pages at the correct physical addresses?
You can load multiple pages in a single read operation, yes, and do less computation when trying to load/purge on a per-page basis (instead of a lookup table you just do a single addition)
Re: On ELF, Part 2 (2018)
#18> "the big mistakes from Unix, besides the X Window System"
The entire X11 system was "a mistake". Got it, we should have stuck to 7-bit text on a VT-100 because that was utter perfection.
With that compelling intro I lost any interest in any other arguments the author presented.
Re: On ELF, Part 2 (2018)
#19Off topic — does anyone know more about what happened to the Kestrel project? It sounds from the note in the archived GitHub project[0] like the maintainer shut it down because a company released a similar product with the same name. Seems odd (and sad). [0] https://github.com/KestrelComputer/kestrel
He has a post with some details here: https://kestrelcomputer.github.io/kestrel/2017/03/07/kestrel...
Seems that precedes the ultimate end: https://kestrelcomputer.github.io/kestrel/2017/11/22/kestrel...
Re: On ELF, Part 2 (2018)
#20> "the big mistakes from Unix, besides the X Window System" The entire X11 system was "a mistake". Got it, we should have stuck to 7-bit text on a VT-100 because that was utter perfection. With that compelling intro I lost any interest in any other arguments the author presented.
The author seems to be an Amiga fan. I suspect it's not the idea of a graphical UI he's complaining about. Just the specific implementation.