←back to thread

Wild – A fast linker for Linux

(github.com)
383 points hkalbasi | 1 comments | 24 Jan 25 16:25 UTC | HN request time: 0.203s | source
Show context
devit ◴[24 Jan 25 16:49 UTC] No.42814926[source]▶
I think the optimal approach for development would be to not produce a traditional linked executable at all, but instead just place the object files in memory, and then produce a loader executable that hooks page faults in those memory areas and on-demand mmaps the relevant object elsewhere, applies relocations to it, and then moves it in place with mremap.

Symbols would be resolved based on an index where only updated object files are reindexed. It could also eagerly relocate in the background, in order depending on previous usage data.

This would basically make a copyless lazy incremental linker.

replies(9): >>42815042 #>>42815180 #>>42815279 #>>42815434 #>>42815474 #>>42815621 #>>42815660 #>>42815894 #>>42815895 #
1. 95014_refugee ◴[24 Jan 25 18:00 UTC] No.42815621[source]▶
This makes some very naïve assumptions about the relationships between entities in a program; in particular that you can make arbitrary assertions about the representation of already-allocated datastructures across multiple versions of a component, that the program's compositional structure morphs in understandable ways, and that you can pause a program in a state where a component can actually be replaced.

By the time you have addressed these, you'll find yourself building a microkernel system with a collection of independent servers and well-defined interaction protocols. Which isn't necessarily a terrible way to assemble something, but it's not quite where you're trying to go...