Re: Shared libs.

[dsb@goldfinch.cs.duke.edu (Scott Bigham)]

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

						-sbigham