William Harold Newman <william.newman@...> writes:
> My first impulse is to do something like (1), though
> (a) probably through the *BEFORE-SAVE-INITIALIZATIONS* /
> *AFTER-SAVE-INITIALIZATIONS* mechanism instead of a new
> "remember to tweak environ here" step in toplevel setup, and
> (b) ideally by making this happen automatically for all
> foreign symbols which need this treatment, instead of
> as a special hack just for environ, e.g. perhaps DEF-ALIEN-VARIABLE
> should automatically install hooks in *AFTER-SAVE-INITIALIZATIONS*
> to update the address it refers to
Ah, there's an *AFTER-SAVE-INITIALIZATIONS* mechanism. Yes, that
makes sense.
> But I don't know much about the problem. In particular, I don't know
> enough about the problem to guess what's required to make (b) happen.
> Is there something special about environ (like the way that errno is
> very special)? Or is this a general problem with any variable? Or any
> label? (including function addresses?) What kind of magic does C code
> use to avoid this problem?
It's just a normal variable. I expect, though haven't checked, that
function addresses have the same problem. C code resolves names to
addresses at startup time, instead of three months earlier at core
dump time, so it doesn't have the problem.
> I notice on OpenBSD that environ is in sbcl.nm. Perhaps what's going
> on is that it's in sbcl.nm in Linux too, and SBCL figures that it
It's not. I assume that OpenBSD is statically linked against libc.
> knows where environ is for all time, when in fact that's not a safe
> assumption? If so, does anyone know for which other labels this is not
> a safe assumption? Should we stop using sbcl.nm to get to variables?
sbcl.nm should be safe for anything in our own runtime or statically
linked to it - in other words, for any symbol that it lists. But
the lookup used by def-alien-variable will go off and try dlsym() if
it can't find stuff statically.
environ is - as far as I can determine using grep(1) - the only
occurrence of def-alien-variable in the SBCL code at present,
incidentally.
> Incidentally, I can see that this could be a really annoying problem,
> so if there's any difficulty making an elegant solution, I'd be
> willing to merge a quick and dirty patch for the meantime, at least as
> long as it didn't look too dangerous.
For the moment, for the .deb, I'll add something to /etc/sbclrc: this
is a sufficently ugly solution to goad me into doing something
elegant, and easily reversible when the elegant thing does happen. I
guess the right thing to do is go away and read
*{before,after}-save-initializations* stuff, and see how to do it with
that.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
|