Re:Zig's New Relationship with LLVM
by kristoff_it on Monday September 28, 2020 @09:03AM
(#24616179)
> Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places?
Yes.
> Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places?
I'm not an expert, but I believe the point is mostly about other computation required for "normal" linking, not just writing fewer bytes to disk.
> What other benefits is this supposed to have?
It makes the edit-compile-run loop faster when developing.
> Does linking somehow get faster or easier with in-place patching?
That's the idea. When code isn't position independent, moving a chunk of code requires recomputing a bunch of offsets, and similarly the linker needs to do more work when you don't have an indirect way of referring to functions etc.
Yes.
> Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places?
I'm not an expert, but I believe the point is mostly about other computation required for "normal" linking, not just writing fewer bytes to disk.
> What other benefits is this supposed to have?
It makes the edit-compile-run loop faster when developing.
> Does linking somehow get faster or easier with in-place patching?
That's the idea. When code isn't position independent, moving a chunk of code requires recomputing a bunch of offsets, and similarly the linker needs to do more work when you don't have an indirect way of referring to functions etc.