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 relocation? 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. Take care, Matthew Wilcox <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/gcl-devel > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
