Re: Shared libs.

[hohmuth@inf.tu-dresden.de (Michael Hohmuth)]

Following up on my own article, here are some more things now that
I've thought over the matter for a while.

Michael Hohmuth wrote:

> -   A shared library's code needs to use base relative addressing for
>     data in DATA and BSS segments or it cannot be shared. :-)

This is not quite true: The real requirement is that the library's
TEXT segment needs to be read-only.

The current MiNT way to implement this is to use base-relative
addressing to the DATA/BSS segments.  However, there are other ways,
and, as we will see later, base-relative addressing alone does not
necessarily fulfil the requirement mentioned above.

The SunOS (and BSD) way is to use an additional level of indirection
to access external data and functions using tables which reside in the
shared object's DATA segment (global offset table, procedure linkage
table).  This must be supported by the compiler (the "-pic" flag
triggers the usage of the tables which are often addressed by another
register; `gcc' supports this), the linker (which allocates the tables
in a shared object's DATA segment) and the runtime link editor (which
resolves the dangling references in those tables).

(BTW, if a program uses its global offset table to reference its own
data, it does not even need base-relative addressing to be shareable;
this also circumvents the data+bss < 64K problem.  This is of course
slower, however.)

> -   We want to be able to access static data in a shared library, not
>     just functions.
> 
> -   Shared libraries have their own DATA and BSS ranges which need to
>     be instantiated for every process using them.

Because of these two demands, base relative addressing alone will not
suffice: We can't dereference an external symbol without relocating
the reference first, but since the text segment should be read-only
(at least for shared libraries and shared text executables), we can't
modify the text segment.  Therefore we need an additional level of
indirection such as the SunOS one I mentioned above.

> 2. Base-relative addressing a shared library's DATA and BSS segments:
> 
> I think every instance of a shared library needs its own base
> register.  This could be either
> 
> (a) the same register as usual (a6?) (Chris)
> or
> (b) another register, e.g. a5.

As it is impossible to use up another register for every new shared
library, me must go for (a) here.


Andreas Schwab wrote:

> |>     Of course, we would want to create these stubs automatically; this
> |>     would probably require changes to the linker.  Also, some shared
> |>     library manager would need to be implemented.
> 
> You might want to look at the DLL tools for Linux, which do this
> automagically.  But they require a 68020+.

Where can I find those?  (I suppose you mean some Linux/68k-specific
tool?)

Some more pointers:

NetBSD/Atari supports SunOS-style shared libraries, and their linker
is very similar to our bammi linker (derived from the same GNU `ld').
If I were to implement shared libraries for MiNT, I would probably
start with this package:
<URL:ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/gnu/usr.bin/ld/>

`dld' is a dynamic link editor which presumable also runs on the ST.
The original GNU version which has been ported to the ST is at
<URL:ftp://prep.ai.mit.edu/pub/gnu/dld-3.2.3.tar.gz>, the latest
available version is
<URL:ftp://prep.ai.mit.edu/pub/gnu/jacal/dld-3.2.6.tar.gz>.


I wonder if anybody actually reads up to this line. :)

Michael
-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/