[Gcl-devel] Re: lisp:let problem

[Camm Maguire]

Greetings!  If you could provide more specifics, that would of course
be nice.

One thing that is very clear about gcl is that most bugs are difficult
to pinpoint, mostly because of the garbage collector.  By the time you
see a segfault, usually the damage has been done long before.  So from
what you tell me below, one need not immediately expect a loading
error.

If there were a genuine fasloading bug, it should appear basically on
*every* file.  Getting errors only on some files indicates something
else.  

For example, on m68k, I've traced the first maxima compile failure *to
the lisp compiler*, which failure is in turn most likely due to a gc
failure.  The lisp compiler produces a "data" file which is basically a
binary representation of the linked list of the files lisp objects.
This is appended to the end of the .o file produced by gcc from the .c
file also output by the compiler.  The data file and the c file should
be architecture independent modulo header differences.  The m68k
compiler made a clmacs.data differing from the i386 by about 6 bytes
in isolated positions.  Taking the i386 data file, appending to the
m68k gcc-produced .o file, and loading works fine.  I believe this is
what is going on in most of the instances involving reports of "Dots
appeared illegally."  

I need to figure out a way to see if I can just load all the maxima
.lisp files directly without compilation, and then save
raw/saved_maxima, and see if this passes the tests.  If it does, then
maybe there is a compiler miscompilation on these platforms -- if it
doesn't then it seems like a gc issue.

I'm beginning to think that we are not going to make much progress at
all in debugging unless we can isolate the gc.  I simply have no good
way of chasing down a gc bug.  Even setting watchpoints at addresses
in gdb *changes the location and nature of the error* with such bugs.
For this reason, I do think we need a libgc *option*, even if we never
use it on most machines due to its likely sub-optimality.

And as for the libbfd, for right now, its just used for relocations on
elf systems.  As far as it goes, it seems to work, but as we've stated
before, we don't have a second Linux elf platform beside the i386
making a correct maxima.  If we get to that point, I'd like to rewrite
sfaslelf.c as sfaslbfd.c, and use it for coff, etc. as well.  the
interface is not as flexible as I once thought.  And it does use
malloc when one opens a bfd, so I had to get our malloc to redirect
these requests to a static buffer away from the heap.  One problem is
that I don't know how to get a bfd to point to a location in memory as
opposed to a file portably across many platforms.

Apart from this, the link supplied by David Billinghurst seems to
indicate that some windows CE people have replaced the fasloading with
dl loading.  check out sfasdl.c, or something like that.  It will
change things quite a bit, like making saving a system image
impossible, but should be more portable, and is on our long term todo
list. 

Take care,

Dan Stanger <address@hidden> writes:

> I have traced the problem to a segfault occuring in a typecheck, which
> happens during
> fasload.  I remember you mentioning replacing fasload with libbfd, or
> was that just the
> relocation stuff.  I would rather not fix this code if it will be
> replaced.
> Dan
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah