axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] A modest proposal


From: Ondrej Certik
Subject: Re: [Axiom-developer] A modest proposal
Date: Wed, 4 Jul 2007 21:01:33 +0200

Were it only that simple.  Typically, many, many failures are required
to get a working build on a lesser known machine.  gcl/axiom flushes
out instabilities in gcc, binutils, and several other very low-level
parts of the toolchain.  That said, getting all the builds working
flushes out bugs in gcl too.

At least the bugs in the toolchain are discovered.

Witness the issues at present: gcl switch statements apparently
generate bogus jump table assembler on mips, gcc-object-inserted
symbols __divq/__remq on alpha are apparently uwrappable (*), new
GPREL_32 relocs in the new .rodata section needed support on alpha,
new GNU_HASH section types required binutils patches, etc.

(*) As you know, GCL loads object (.o) files into a running image,
which can then be dumped and executed later.  It therefore needs the
ability to relocate all symbols in the .o file.  Relocating to
addresses in external shared libraries is dangerous, as the lib may
not be in the same place on image restart.  2.6.x had a plt mechanism,
which attempted to force gcc to provide local addresses by compiling
in functions using the addresses of the external functions.  This
broke with subsequenct gcc developements, so even with the plt,
relocations were being set to shared library addresses on some
machines.  Now, 2.7.0 redirects all such calls through a pointer in
the C source which is reset on image startup.  __divq and the like,
alas, have no representative in the C source, and cannot be handled
thus.  Ideally, we can define a wrapper function and relocate to that,
but this procedure has been problematic with mcount (for example) on
s390 and ppc.  (just a taste ... :-)

So the problem is actually in GCL, that it is still not stable enough
to do some serious work on top of it?

I am just surprised, how many problems there are just with compiling.
I myself use Python/C/C++/Fortran and never had experienced any
problems like that. So maybe the lisp is not a mature platform for
larger projects? My naive opinion is that one should try to stick to
ways of doing programs that everyone does, so that such low-level bugs
are already fixed.

Ondrej




reply via email to

[Prev in Thread] Current Thread [Next in Thread]