Re: gclcvs_2.7.0-43
Greetings, and thanks fr your reply!
Stephen Frost <sfrost@snowman.net> writes:
> * Thiemo Seufer (ths@networkno.de) wrote:
> > Camm Maguire wrote:
> > > OK, I found a genuine problem which I've corrected in the latest
> > > upload (which became apparent when mips and mipsel failed in exactly
> > > the same placeO), and now we're still back at a mipsel pass and a mips
> > > failure. Would you mind veryifying that this is not due to some
> > > physical problem on the mips buildd? (Or perhaps indicate that I
> > > might be granted an exception to the prohibition on casals for doing
> > > by hand builds? Is there any other developer machine for this
> > > purpose?)
> >
> > It builds fine here. The buildlog message from r5k
> >
> > Error: Caught fatal error [memory may be damaged]
> > Error signalled by RAISE-METATYPE.
> > Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
> > PCL>>
> >
> > suggests some brokenness on that machine.
>
> Not so much. I tend to doubt it's a problem with the box. It's running
> a slightly older kernel (.25) and there were some kernel messages
> regarding this:
>
> saved_ansi_gcl: Forwarding exception at [<880d5920>] (881c34fc)
> saved_ansi_gcl: Forwarding exception at [<880d5928>] (881c3508)
>
Could you please explain the meaning of these messages? Last time I'd
seen similar was on a solaris machine which pushed non-fatal notes to
the system log everytime a program tried to execute code from its
.data section, which gcl does all the time. If I can get ahold of the
saved_ansi_gcl image, I can also tell you where these addresses are of
course. The real problem is that without a machine, I can't do
anything about this myself.
Just to recap, I've recently added native code relocation to GCL on
mips/mipsel, which joins all the Debian platforms except ia64 and hppa
now in this regard. Object files are compiled from lisp via C to
native code, relocated into the running image in such a way as to
preserve them when the image is dumped via unexec, and makes the
loaded memory executable, flushing caches if necessary. This is a
longstanding though unconventional lisp development model in current
use by maxima, axiom, and acl2.
My guess is that the kernel on r5k might have some configuration
setting which is complaining about this.
Take care,
> Those were the only kernel messages since boot though, and it's not like
> this box is idle much. :)
>
> It might be interesting to see what happens when trying to build it on
> hawking, or maybe try a new kernel on r5k.
>
> Stephen
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: