Re: Shared Libs for Mint

[Howard Chu <howard@harry.lloyd.com>]

  With X11 in mind I spent some thoughts on whether and how shared libraries
  could be implemented for Mint.
  
  My first thought was to compile the library -mbaserel and generate a stub
  out of it that is linked to the binary instead of the whole library.
  
  The stub functions would then (when first called) somehow create BSS and DATA
  segments for the to be loaded lib.

You've hit upon the exact same thoughts I had when first pondering this
problem... For BSS and DATA, you can take one approach - assume the shared
library will never change its variables from version to version, and then
just statically bind them when linking the program to the stubs. Or you
create a data table in the text segment, describing what to malloc. Then
you're free to redefine the variable usage with successive updates to the
library code.
  
  The code segment of the library would be shared between applications using
  the same library. That of cause requires the stub functions to fiddle around
  with the basepointer in a4 so the library code accesses the right DATA/BSS
  segment.

This is where major difficulties arise. How do you keep base pointers straight, especially if one library refers to a different library? (e.g., any reference
to errno, curses into termcap, etc...)
  
  But problems arise if the shared library calls functions (passed as pointers
  to the shared library routine) that are part of the text segment of the
  application that is compiled -mbaserel. (One prominent candidat is the qsort
  function). Then when the comparision function that is passed to qsort is
  called the base pointer would still point to the DATA/BSS segment of the
  library where the application code expects it to point to the app's own
  DATA/BSS segment.
  
  Any solutions or better concepts? (How do for instance Windows DLL's work?
  They haven't got a virtual memory managment system either. As far as I
  remeber you must tell the compiler to load the DS segment register (which
  points to the data segment) on every function call...?)

I had considered special-casing things; as you note, qsort is one of the only
problem cases of calling back to the user. But there may be a better way...
  
  One drawback of this idea is that the libary cannot contain DATA/BSS segments
  greater than 64k. I don't know whether this would be still useful for things
  like libXt or libX? How large are their DATA/BSS segments?
  
The 64K limitation is too severe to continue with it. Instead, we need to
implement separate blockdata, blockbss and data and bss regions. For any
variable greater than 4 bytes, locate it in the block region and leave a pointer
to it in the data region. This extends the shared text usefulness by a huge
amount... (And I've talked about this for months now, but haven't yet got a
stable set of patches written for it. sigh...)

Ok, here are some more ideas... Shared library code eats up another address
register, and the library uses that to point to its own data/bss. The reg
is loaded by the stub routines.

Dynamic linking is somewhat complicated. Each program needs a table of the
library name and each symbol referenced in that library. The linker must
access the library and relocate every program reference to a library symbol.
This is a pain if the library data is malloc'd, less of a problem if it's
statically linked.

  
  Kay.