Re: Shared libs.

[hyc@locus.com (Howard Chu)]

  >There is an easy way to solve the problem of local (to a process) variables.
  >Whatever you do you'll need stub routines to link to when you build the
  >executable, so why not get these to allocate all the variables in a block
  >and then pass a variable base pointer to the shared routine?

  You don't actually have to allocate anything, in the sense of malloc().
  Just have the variables live in the stub (perhaps bundled into a struct
  so we can pass them in with a single pointer).

  >The only problem you may have is if the program is pre-empted whilst inside
  >the shared routine, in which case we have to make sure that the routines are
  >fully re-entrant, say by using the current pid as a redirection pointer to
  >local variables or something (though this may need some help from the
  >kernel).

  Actually, I don't think this will be a problem.  Remember, the shared
  routine is running in the context of a particular process.  Its
  non-static local variables and arguments are on the stack, which is
  disambiguated by the current process' A7, or perhaps in registers, which
  is disambiguated by the current process' register set.  Its static local
  variables are accessed via a pointer which is an argument to the
  function, so it's covered by the above.  Non-local variables have to be
  pointed to somehow, but as long as the "pointer" lives in a register or
  a function argument, it's covered by the above.  The current point of
  execution in the shared routine is disambiguated by the current
  process' PC.  Am I missing anything?

No, I think you've got it all here. The trick now is to make all of this
happen automatically. We really want to be able to take any arbitrary library
source, compile & link with a special flag, and have the compiler and linker
automatically generate the stub function, static structure, etc.

It would simplify things if we could require that shared library be a fully
linked object file, without any unresolved external references, but I guess
that might be too much to hope for. Again, errno is a prime example of the
problem with that. The only automatic way I can see to handle this is if we
do something special with "extern" declarations. E.g., if a source file is
being compiled with the shared-library option, then extern declarations are
treated as if they were external to the entire library. In this case, they
would be referenced through a pointer, instead of directly. Or we could go the
ugly DOS way, and introduce the concept of a FAR modifier...

The linker should generate both a shared library file and a stub library file;
the stub will contain the function entry/exit code as well as the entire
data segment for the library. The entire data segment will need to be linked
into a program as a single unit...