Re: Shared libs.

[Wolfgang Lux <lux@heidelbg.ibm.com>]

Michael Hohmuth wrote:
> 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

I recall, that the 68k version of GCC does not (yet?) support -pic (or
is it -mpic?). BTW., I'm not quite happy if the compiler must have to be
changed. There (still :-) seem to be people out there that do not use
GCC (or am I wrong on that subject). Pure C won't work if it even does
not support baserel addressing, but Lattice C supports it (at least
that is what I read from the posts on this subject), so I would favor
if we could get shared libraries working for both, GCC and Lattice.

> 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.)

and it shouldn't have more than 8k global variables and functions :-)

> 
> > -   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

That's right. The pointer to the libraries data segment must live in
the executables data segment (and would be initialized at startup time
when the shared library is actually linked).

> indirection such as the SunOS one I mentioned above.
> 
[ ... ]
> 
> 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>.
> 

Don't confuse shared libraries and dynamic linking. They are both
related but it is not the same. I have been using dld (3.2.3) some
time ago when programming with scm (the scheme interpreter which is
the base of jacal) and it works quite nice under MiNT. But it does not
help us anything on the subject of shared libraries. Dld loads the
object modules and libraries into the data segment (sic!) of the
executable, so you end up with `n' instances of the library if you load
it into `n' executables. :-(

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

And I wonder, if anybody actually will read one line further :-)

Regards
Wolfgang

----
Wolfgang Lux
WZH Heidelberg, IBM Germany             Internet: lux@heidelbg.ibm.com
+49-6221-59-4546                        VNET:     LUX at HEIDELBG
+49-6221-59-3200 (fax)	                EARN:     LUX at DHDIBMIP