Aaron Sloman <A.Sloman@cs.bham.ac.uk> wrote:
> I have mentioned previously that poplog will not run, and cannot be
> linked on recent versions of linux -- e.g. I could not run it when
> I temporarily installed fedora core 4, and when I installed a new
> kernel with number above 2.6.11-1.27
>
> The symptom is that I can run basepop11, and then compile arbitrary
> pop11 code and run it, but if I try to run pop11, or xved, or anything
> else that requires starting basepop11 together with a saved image I
> get a 'segmentation fault', though I recently found that it was random:
> i.e. I usually get the fault but not always. I cannot imagine what
> there might be about starting up a saved image that would randomly
> fail.
I vaguely remember reading something about relocating
runtime(?) libraries in new(er) versions of the kernel. Does
this spark any recollections or ideas in anyone else? The
implication was that libraries might be linked into different
parts of the address space on different "runs" of the same
program.
Poplog saved images depend crucially on the base they are
being loaded into being the same as the one they were
compiled under, so if any parts of that base are loaded into a
different part of the address space, you'd get segmentation
faults ...
The problem is, I can't remember *why* -- it must have been
something to do with sharing libraries, but that's an inference,
not a recollection. (If program A loads a runtime library X,
then loads a runtime library Y, and then program B loads runtime
library Y, then if Y is shared with A, it may use different
addresses than if B ran first, and loaded Y first. Whereas if
B doesn't share Y, it will always be loaded into the same address
range. You might think that with virtual address spaces this
need not occur, but runtime libraries have to be linked, same
as static libraries, except that this linking is part of the process
of loading the runtime library. If runtime libraries had "fixed"
pieces of virtual address space, you'd get problems with
collisions, unless all the code was pure relocatable. And, IIRC,
in general it isn't.)
I'm hoping that someone will recognise what I'm talking about
and say something like, "Oh, yes. In that case you just need to
start with the foo flag, or run the set-no-barf-option," or
something.
Coincidentally, I've spent several tens of hours this month
designing and implementing a "portable byte code" format for
the poplog VM - this would allow progs compiled under Windows
to be loaded in Linux and vice-versa, or progs compiled under
one version of poplog to load under another. So, for example, it
would enable me (or anyone else) to "deliver" using a stripped
down poplog which lacked most of the compiler (syntax procedures)
and editor, although it would still need the run-time code
generator (everything that happens after sysPOP, sysCALL
etc.)
It should make porting Poplog to new platforms a lot easier
too ...
And although not a complete replacement for saved images it
would be intrinsically more robust and a useful alternative in
many situations.
But there's still a lot to do ...
Jonathan
|