[Gcl-devel] ALPHA native object relocation committed to gclcvs

[Camm Maguire]

Greetings!  Happy to announce that native relocation is now also
enabled for the alpha following the mips .got-section-per-module
strategy.

Leon Bottou <address@hidden> 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                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah