Jonathan L Cunningham writes:
[AS]
> > 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.
>
[JLC]
> 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 ...
This sounds like a plausible explanation but for one problem: if I
get a new kernel (even the latest stable one: 2.6.15.1) and compile
it myself, I don't have the problem.
So recent kernel features are not enough to cause the problem.
If I get a pre-built kernel later than 2.6.11-something I get the
problem.
Is it possible that some ways of compiling the kernel produce that
effect which is not turned on by default in the kernel sources, but
is turned on in new pre-built Fedora Core 3 and 4 kernels?
I could try searching through the config files which determine what
goes in to the kernel when it is compiled, but linux kernel config
files are huge: there are so many options that I fear I would not
even recognise the one that's relevant, if there is one.
The other possibility is that people who produce pre-built kernels
compile them in an environment that's different (gcc4 libraries
vs gcc3 libraries?). If different static libraries are included in
different versions of the same kernel that might cause problems.
In that case I am surprised nothing breaks apart from Poplog.
> ..... 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 must look again at the switches available for creating system
saved images (in sys_lock_system, used by mkimage) to see whether
something there could be the basis of an experiment to test
jonathan's hypothesis.
E.g. saved images are created as shareable by default (which can
save startup time and memory) but maybe that's incompatible with
some memory management systems.
> 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.)
Reminds me of something Steve Hardy did to speed up compilation of
pop11 libraries on the PDP11 computer around 1976. He wrote a
program that compressed a file, removing all redundant white space,
and if I remember correctly doing something else, e.g. replacing
all the words with unique numbers and saving a mapping between the
numbers and the words at the beginning of the file.
That meant that the work of the itemiser was significantly speeded
up.
Some possibly relevant techniques are used in LIB DATAFILE
Later on John Gibson tried to implement 'incremental' saved images,
which had something like the features you describe, but they never
worked reliably.
One of the reasons for using saved images has gone. It used to take
15 minutes or more to compile startup.p on the suns we used in the
early 1990s at Sussex. On my 5 year old 1.5Ghz pentium 4 in my
office it takes about 8 seconds compiling files located on a shared
NFS server (1.73 secs cpu time).
On an 8 month old AMDpentium64 2GHz on my desktop at home it takes
about 3 seconds.
I used to create and use saved images built on top of startup.psv
(pop11) until about 5 years ago. Then I stopped because compiling
was so fast.
When will we stop using the system saved images and define pop11,
prolog, xved, clisp, pml as shell scripts that compile what's needed
instead of invoking a saved image?
Perhaps the solution to my original problem is to move in that
direction!
The shell scripts could also be used very easily to avoid the need
to set environment variables before starting pop11, etc. E.g. they
would source the user's ~/.pop11-init or ~/.xved-init etc.
before they start compiling.
Then basepop11 will be the only binary needed for normal use, and
poplog will be more portable! Poplog subsystems will still start up
faster than many things most PC users live with.
Of course, for people using systems with 100 times as much code to
compile, saved images could still be useful for a few more years.
Aaron
>
> 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
|