[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shared libs.



Michael Hohmuth wrote:

> For example, let's consider 2 programs, BAR and FOO. BAR uses libraries A,
> B, and C; FOO uses A, C, and D.
> 
> BAR's data segment will look like this: (assuming that A, B, C, and D are
> the first 4 libraries loaded, and were loaded in that order)
> 
> ------------------------------------------------------------------------------
> | A's data |   B's data   |   C's data  |           BAR's data               |
> ------------------------------------------------------------------------------
> 
> FOO's data segment will look like this:
> 
> ------------------------------------------------------------------------------
> | A's data |   FOO's data |   C's data  |  D's data  |  more of FOO's data   |
> ------------------------------------------------------------------------------
> 
> Note that FOO's data segment is split up. This is because library C expects
> its data to come at a certain offset (after A's and B's), and so C's data
> segment in process FOO must start at that offset.

I definitely don't like this part. Since the shared library functions have
to use a base pointer register anyway, there is no reason to have their
data sections at a fixed offset. With these fixed offsets the number of
shared libraries will be limited (mc68000 doesn't allow 32 bit offset).
Also each shared library has to be registered to prevent clashes.

It's much cleaner to keep the data sections for the main program and for
each shared library completely seperated. In this case each library and
the main program can access upto 64KB of static variables.
 
> The disadvantage of this scheme is that once more than 64K of data is
> filled up, libraries and/or programs that use 16 bit offsets will be
> in trouble. There are ways around this, of course.

Yep, the best workaround is separate data sections.


Waldi