4 ms·

I think incremental linking is already a thing. It involves leaving bits of unused space in the binary to deal with minor changes in the size of the object file

I think incremental linking is already a thing. It involves leaving bits of unused space in the binary to deal with minor changes in the size of the object file. I can't remember if Sony shipped that with the PS4. Pretty sure Microsoft had a version for the Xbox at that time. Unloading code while running is difficult. Dlclose doesn't really know whether anything is still holding onto pointers into the shared library. What would probably work is compiling each object into a shared library and otherwise disallowing shared libraries. That would ensure the loader has a consistent model of which addresses have been patched to which shared library and give a relatively sane way to unload and replace at that granularity. Moving symbols between object files during linking would be tricky.

slaymaker1907 4y ago
There's actually pretty simple solution to the loading/unloading problem if you can assume that function signatures do not change. Just generate a wrapper function which has a R/W lock and then just calls the actual implementation while holding a R lock. To update the implementation, acquire a W lock and replace the implementation. There is overhead, but I don't think it would be too bad. You could also probably reduce the overhead by doing something fancier like having the daemon inspect the stack frames of other threads (which is expensive, but presumably updates are extremely rare compared to calling functions).
- KerrAvon 4y ago
  It's not (just) a low-level synchronization problem, though; it's a larger structural problem. Simple example: If someone has a reference to your function that free()s some pointer, and your function has been replaced with an inert no-op, that pointer is no longer freed when it should be, and you have a memory leak. Extrapolate this to more complex code. Put another way, assume that you solve low-level threadsafety/data race issues. You still have to design the library from the start to be unloadable; you can't unload code that isn't expecting to be unloaded without undesirable side effects.
  - slaymaker1907 4y ago
    You typically wouldn't replace a function with a no-op since changing who allocs/frees memory is almost certainly an API change which I never claimed my solution would support. The thing my solution would be useful for is for fixing small errors that are tedious to go through a whole compile cycle for. It would be a replacement for modifying values directly in the debugger to try and fix issues (to see if the fix works) and not turn C++ into LISP.

slaymaker1907 4y ago

There's actually pretty simple solution to the loading/unloading problem if you can assume that function signatures do not change. Just generate a wrapper function which has a R/W lock and then just calls the actual implementation while holding a R lock. To update the implementation, acquire a W lock and replace the implementation. There is overhead, but I don't think it would be too bad. You could also probably reduce the overhead by doing something fancier like having the daemon inspect the stack frames of other threads (which is expensive, but presumably updates are extremely rare compared to calling functions).

KerrAvon 4y ago
It's not (just) a low-level synchronization problem, though; it's a larger structural problem. Simple example: If someone has a reference to your function that free()s some pointer, and your function has been replaced with an inert no-op, that pointer is no longer freed when it should be, and you have a memory leak. Extrapolate this to more complex code. Put another way, assume that you solve low-level threadsafety/data race issues. You still have to design the library from the start to be unloadable; you can't unload code that isn't expecting to be unloaded without undesirable side effects.
- slaymaker1907 4y ago
  You typically wouldn't replace a function with a no-op since changing who allocs/frees memory is almost certainly an API change which I never claimed my solution would support. The thing my solution would be useful for is for fixing small errors that are tedious to go through a whole compile cycle for. It would be a replacement for modifying values directly in the debugger to try and fix issues (to see if the fix works) and not turn C++ into LISP.