Greetings! Am happy to announce that GCL's mips/mipsel port, together with the maxima, acl2 and axiom packages carried there (at least on Debian), can now natively relocate compiled lisp object modules on load, save new images via unexec, and preserve the previously loaded code on re-execution. This leaves only alpha, hppa, and ia64 as "second-class-citizen" GCL ports which must rely on ld and special code to recreate the lisp heap from scratch on each image save. Native relocation is not only more efficient and incremental, but enables many operations to proceed, such as rebuilding axiom's databases and compiling acl2's closures, which could not otherwise due to system resource limits, most notably the max of 1024 open file descriptors for dlopen.
The code has been modified from that supplied in the lush source tree in dldbfd.c, and is therefore brought into GCL under the terms of the GPL v2. The native relocation is bfd-based, not based on the original x86/sparc only "custom" GCL relocation code, so does not change the GPL license which GCL acquires via bfd in this case. Some small modifications were required, many to preserve GCL's use of bfd_get_relocated_section_contents in the other ports, as opposed to lush's direct call of bfd_perform_relocation. All this really means is that the new .got section builds its new relocs directly into the relocation array of the section structure, as opposed to a canonicalized pointer list. Details available on request. The beauty from lush preserved here is that most of the heavy lifting can be done by a simple wrapper around the howto functions, which are installed directly into the newly opened bfd around the original functions provided by the library. It is not immediately clear to me whether some or all of this functionality could be proposed as a patch to the binutils development team. To be more precise, libbfd at present can correctly relocate section contents in a bfd opened on a compiled .o file via canonicalizing the symtab, setting the values, and calling bfd_get_relocated_section_contents, but only on x86, amd64, m68k, arm, sparc, s390, and ppc out of the box. The new code adds mips/mipsel to this list through runtime patches to the bfd library, and opens up the way at least for alpha, it would appear, due to the common gp register handling. The essence of the idea is that one creates a .got section for the new bfd before relocating, and wrapping the howto functions to redirect _gp_disp relocations to the .got via the runtime patches. I am wondering whether the lush people would be interested in collaborating on: 1) doing similar for ia64, hppa and alpha (lush is known at least to be unable to relocate modules on hppa, and I strongly suspect the others follow as well.) 2) finding a way to incorporate gprof information if any in the compiled and loaded module. lush already appears to have a way of handling references to dlopened libs from within the compiled modules, but it is not clear to me how this information is preserved on dumping the image/state. GCL uses unexec, which we would like to extend to be able to write a .plt section or some such other signal for ld.so to require the shared lib on re-execution of the saved image and to handle the new symbol relocations as it would any original symbols say in libc compiled into the original image. This is the only other instance (using new shared libs) for which GCL must rely on ld at present. This will obviously take some time to test adequately, but pcl, which does a lot of loading, has been built successfully on an indy to which I have access. We'll probably release 2.7.0 as a new stable sometime this summer, and rebuild maxima/acl2/axiom across all Debian arches at that time, for the definitive test. Aurelien, you might want to look at the new sfaslbfd.c, as i had to do some rearranging. You can see from the comment where I think your special code should go, but I haven't moved it pending your input. Take care, -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel