Re: [Gcl-devel] Re: gcl/maxima on hppa

[Camm Maguire]

Greetings!

One more observation here which may be helpful -- on hppa, malloced
memory starts at ~ 0x200000 and the stack counts *up* from ~
0xb0000000.   gcl can deal with this without difficulty, except for
the fact that variables declared *volatile* have addresses in the
0x7a0000 range.  This puts them in the middle of the lisp core, which
is sure to messup the gc.  I can either try eliminating the volatile
declarations, which will likely lead to clobbering errors, or find a
way to start malloc and sbrk at say 0x1000000, and treat the 0x7a0000
range as a separate stack for the gc.  This looks like the two stack
setup on ia64 somewhat.  As a third possibility, I could find a way to
put volatile variables on the main stack.  This would e the easiest of
course from gcl's end.

Can anyone advise here?

Take care,

address@hidden (LaMont Jones) writes:

> On Fri, Sep 13, 2002 at 10:17:04AM -0400, Camm Maguire wrote:
> > Greetings!  I think I may have stumbled on a possible explanation for
> > gcl's build failure on hppa.  Hppa alone will not relocate (i.e. allow
> > dlopen to open) modules not compiled with -fPIC.  All other
> > architectures on which dlopen is currently used (alpha, ia64, mips,
> > mipsel)
> 
> Actually, mips and mipsel force -fPIC on all compiles.  The spec requires
> that shared objects be built with -fPIC.
> 
> > 1) gcl can also relocate and load objects via a direct call to the BFD
> >    library routine bfd_get_relocated_section_contents.  This method is
> >    currently used as the default on i386, sparc, ppc, s390, m68k and
> >    arm.  It is not yet fully implemented on hppa.  Completing this
> >    routine should enable a fully functional gcl, maxima, and in the
> >    hopefully near future acl2 on this platform.
> 
> Cool.
> 
> > 2) Find a way to load objects with dlopen without -fPIC.  Attempting
> >    this results in the error that a certain relocation output by the
> >    compiler cannot be handled by dlopen.  Perhaps there is some other
> >    gcc compiler option short of the full -fPIC which can avoid this
> >    relocation?
> 
> Nope.  The non-PIC is truly not position independent.
> 
> > In either case, I will need a knowledgeable hppa person to advise,
> > discuss and help generate patches for this to get fixed any time soon.
> > Gcl can build its own bfd library, so patches here can be simply
> > incorporated.
> 
> willy would be a good target.  I'm going to be out of town for a couple
> of weeks, but (if it's still pending) I'd be happy to help when I get
> back.
> 
> lamont
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah