Mill Computing, Inc. › Forums › The Mill › Architecture › Shared position-independent code

  • Author
    Posts
  • Zoxc
    Participant
    July 18, 2015 at 10:30 pm
    Post count: 7
    #1934 |

    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?

  • Ivan Godard
    Keymaster
    July 18, 2015 at 10:49 pm
    Post count: 689
    #1935

    The explanation is too complex for here; it needs pictures. We expect that the next upcoming talk will cover it; please be patient.

  • Zoxc
    Participant
    July 21, 2015 at 6:41 am
    Post count: 7
    #1943

    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 Godard
    Keymaster
    July 21, 2015 at 3:05 pm
    Post count: 689
    #1946

    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.

  • Findecanor
    Participant
    February 17, 2023 at 3:00 am
    Post count: 34
    #3834

    I stumbled upon this problem recently, and wondered how it was supposed to be done in the Mill (and other single-address space systems).

    Handling of local references from within dynamically loaded libraries has hardware support, NYF.

    Has it been filed yet, so we could read about it?

    • Ivan Godard
      Keymaster
      February 17, 2023 at 5:55 pm
      Post count: 689
      #3835

      Not yet. We don’t expect any new filings until the reorg.

  • Author
    Posts

You must be logged in to reply to this topic.