Re: [Gcl-devel] Re: gcl/maxima on hppa
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) follow the original Sun dlopen behavior and allow objects
compiled without -fPIC, when once modified with 'ld -shared', to be
accessible via dlopen. And I've just verified that gcl breaks when
compiled with -fPIC on i386, for reasons as yet unknown. I suspect,
however, that as the gcl compiler needs to know the addresses of its
various functions, both in its running .text section and those loaded
into memory managed via sbrk and possibly moved via gbc, that the
position independent code generation of -fPIC might interfere
necessarily with the address discovery scheme.
If true, this leaves two options -- the first far more likely.
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.
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
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
Matthew Wilcox <firstname.lastname@example.org> writes:
> On Wed, Jul 31, 2002 at 06:42:47PM -0400, Camm Maguire wrote:
> > Looking over the boehm-gc code, the only unusual item appears to be a
> > requirement to align malloc results on 8 byte boundaries even when
> > running in 32bit mode.
> surely 16 byte boundaries? some structs are allocated on the stack,
> which we need to do atomic ops on. and we can't guarantee atomic ops
> work unless they're 16-byte aligned.
> > 2) Is there anything unusual about the C stack on hppa?
> it grows upwards instead of downwards?
> > 3) When looking at the situation in a debugger, certain local
> > variables on the stack cannot report their address, apparently
> > indicating they are stored in registers. Is there a way to flush
> > these reliably to memory before collecting garbage?
> umm. no idea.
> Revolutions do not require corporate support.
> Gcl-devel mailing list
Camm Maguire email@example.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah