This whole issue about having global variables in a shareable image
(VMS-speak)/DLL/.so gives me a bit of a headache. Honestly, it would
be oh-so-easier to handle if the access was made through functions
that just returned a pointer to the data.
I've no idea how resolution of symbols is made against this library
form no other operating systems, I'm mostly talking from the VMS on
VAX point of view. On that platform, a "shareable image" is basically
a .exe file with no specific entry point. Instead of that, it has a
transfer vector at the beginning, which is basically a table of JMP
instructions to the routines you really want to run. Function symbols
are really resolved at link time of whatever program you link against
this library, and the transfer vector becomes the target.
Now, global variables are a tricky thing here, because there's no such
thing as implicit double indirection, so making a table of pointers to
the actual objects is not an option. The way you solve it is to do
the following:
- allocate extra space for the transfer vector, so it doesn't grow
too easily when new functions are added.
- after the transfer vector, add a blob of memory to have all the
global variables in. This can be done under VMS, it's not
terribly difficult, just demands some discipline.
With that, we end up with the following:
+--------------+
| TRANSFER |
/ /
| VECTOR |
+--------------+
| GLOBAL |
/ /
| VARIABLES |
+--------------+
| THE |
/ /
| REST |
+--------------+
The result of this, for the shareable image to be backward compatible,
is that the transfer vector has to remain the same size (easy!), the
global variable blob must remain the same size (easy), the global
variables in there must remain in the same order (pretty easy) and
must stay the same size (that might be less easy in some cases).
Now, that is the classical model. However, since we're mixing
functions and variables in one numerical vector, it would probably
mean that holes would be created, especially in the global variable
blob (there are a lot of functions before the variebles are coming).
This can be solved by mixnig transfer entries and global variables in
one vector, but it's very tricky since the variables vary in size.
I'm not sure, but it's possible that this can be handled by the
linker. However, if a variable is taken away (marked NOEXIST in
libeay.num, for example), what size should that hole have? Just
thinking about it makes it rather tricky...
Since a transfer vector entry always has the same size (8 bytes in
this case), things would be a *lot* easier if global variables would
actually be hidden behind accessor functions.
Thoughts?
And oh, please, no holy wars about the pros and cons of different
linking techniques. The VAX technique has the advantage of being very
fast since it does no run-time linking...
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
