- ZoxcParticipantJuly 18, 2015 at 10:30 pmPost count: 7
Normally shared position-independent code refers to a part of the address space that is not shared, so it can access the non-shared data segment associated with the code segment.
Since Mill has a single address space, this does not work. The well-known registers allows access for the executable, but not for libraries. So the question is, how can data and thread-local segments be efficiently accessed from a library on a Mill?
- ZoxcParticipantJuly 21, 2015 at 6:41 amPost count: 7
Another fun thing with a single address space is that you can directly link calls to the loaded library code, instead of using a PLT. So the overhead of dynamic linking would be a 60-bit constant instead of whatever relative calls happen to be.
To do lazy loading of libraries we need to patch the constant to refer to the loaded library. You said that the Mill does not support self-modifying code, which does not bode well for such a feature. Is stopping all threads and flushing just the constant from the instruction cache sufficient?
- Ivan GodardKeymasterJuly 21, 2015 at 3:05 pmPost count: 627
Handling of local references from within dynamically loaded libraries has hardware support, NYF. Handling of inter-library references (the app is just another library) depends on whether hot-swap capability is requested by the ELF file. Hot-swap uses a PLT and GOT for such references, so that the indirection can be changed at run-time. Non-hot-swap uses quasi-static linking at load-time, but no code modification at run-time. Hot-swap code can reference non-hot-swap and vice versa transparently. We expect that the default will be that any explicit use of dlopen will use hot-swap, while dependent libraries (both dependents of the app and dependents of dlopen’d libraries) will be non-hot-swap by default.
You must be logged in to reply to this topic.