Greetings! Happy to announce that native relocation is now also enabled for the alpha following the mips .got-section-per-module strategy.
Leon Bottou <[EMAIL PROTECTED]> writes: > On Sunday 10 April 2005 12:06 am, you wrote: > > Greetings! Am happy to announce that GCL's mips/mipsel port, together > > [...] > > 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. > > Nice. > > > bfd_get_relocated_section_contents > > I remember investigating that one long ago and giving up on it. > Two years ago I looked at your sfas code and discussed with Aurelien > because I wanted MacOSX support in lush. I was quite surprised > that you got it working... > It has taken a bit of time. > > 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.) > > Available time is the key problem for me. > These three platforms are essentially dead or dying. OK, you may want to look at the alpha code now committed if you are ever interested in alpha. > My only recent work on dynamic loading involves widespread platforms: > - x86_64: handling overflows and loading code in the lower 2GB (that is in > dldbfd.c) > - mach-o: alternate dynload code based on the NSModule API (that is in > module.c) > > > > 2) finding a way to incorporate gprof information if any in the > > compiled and loaded module. > > and debug information (gdb) as well! > I can see we are thinking alike. One can't appear to beat gdb's add-symbol-file, but there may be some creative ways to interface from lisp. > > 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. > > Dumping the image state is not done with an unexec trick, but > by parsing an architecture independent dump file and reconstructing > the corresponding lisp objects. Yes this is slower. > Modules are reloaded when the corresponding lisp object is reconsructed. > I see. Why then do you need to relocate at all, as opposed to just dlopen? > Thanks for letting me know of your work. > And likewise! Still would be nice to avoid duplication of effort to the extent possible. Take care, > - Leon Bottou (one of the lush developper) > > > > -- 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