[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] ALPHA native object relocation committed to gclcvs
From: |
Camm Maguire |
Subject: |
[Gcl-devel] ALPHA native object relocation committed to gclcvs |
Date: |
14 Apr 2005 17:41:20 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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