Re: shared libraries for MiNT

[ersmith@netcom.com (Eric R. Smith)]

>I really think we need to have an object format that includes separate
>segments for blockdata, blockbss, and maybe even blocktext for constant
>arrays & structures. That's the only way to insure enough breathing space
>while using 16 bit offsets.

Maybe so. (Text shouldn't be a problem, since I'm assuming that the text
segment is constant, and since references to text don't need to be
base register relative -- the library's text will appear in the "non virtual"
part of every process' address space, i.e. at the same address in every
process.) The advantage of DRI format is that most ST compilers can
spit it out, but if we can come up with a better format and a conversion
tool then we can go with the better format.
  
>Just a minor note, a5 is unusable for this purpose because it is zeroed
>by Supexec. The current baserel stuff uses a4.

a5 is zeroed by Supexec in TOS, or in MiNT? If in MiNT, it's a bug, but
in any case I guess we can stick with a4 for compatibility.
  
>  The data and bss segments of a given shared library will always be
>  located at the same (relative) offset in the data/bss area of
>  a program using that library. (Note that I'm going to call the

>I don't understand how this can be enforced without collisions. Is the load
>address & size of the data section stored in the respective library? What
>happens if the library is revised and the data section changes in size? Also,
>it seems that trying to deal with gaps from unused libraries will be messy...

Sorry, I guess I didn't make that part clear in my post: the load address
of the data section is determined by the kernel when the library is first
loaded from disk. That is, the kernel goes through the list of currently
loaded libraries, examines their current offsets, and figures out where to
put the new library based on that. That scheme should work because a
library must be loaded before it can be used (that's why the shared library
info is prepended to executables linked with the shared libs; the kernel would
have to load those libraries before it loads and relocates the executable,
rather than having the executable do an exec of /bin/ld.so or whatever, as
SunOS does).

>Finally, what about library code referencing data symbols that are external
>to the library? (I think e.g. curses references some of termcap's variables...)

No problem, as long as there's only 1 data space that all libraries share;
that's the advantage of using just 1 base register for all the libraries.
The disadvantage, of course, is that with 16 bit offsets we run out of
room relatively quickly. On 68020+ machines you can use 32 bit offsets
directly; on 68000s you have to do register loading, which is a pain but
I think is do-able. (I think the OS-9 port of gcc does this.)

>Is this scheme going to only support Atari-generated libraries, or will anyone
>be able to write a shared library?
  
Since the data load address is determined at library load time, anyone
can write a shared library -- there won't be any "master list" of
load addresses to update.

>  Another disadvantage is that program load times will be longer, since
>  the kernel is going to have to do the relocation and symbol resolving.

>Meaning that executables must never be stripped, as well, right? And, just
>to clarify, this is not an attempt at providing dynamic loading and linking
>as well, is it? (Oh, I see, you can strip any resolved symbols, of course,
>and only leave the unresolved ones in a program file...)
  
Right, unresolved symbols would have to be left in the binary somehow.
Actually, I guess we could remove even those, if we used a different
object file format that had multiple relocation tables; then the symbols
could be resolved by the linker to something like "12 bytes from the
start of library A's data space" or "20 bytes from the start of the
program data space". That would make things easier for the kernel, at the
cost of leaving the "holes" caused by unused libraries (e.g. if there
are currently 4 libraries loaded, A through D, and a program used only
library D, then the data space that A-C would occupy would have to be
left unused in the program image.)