MIPS native object relocation committed to gclcvs
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
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.
Camm Maguire email@example.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah