Greetings! GCL natively relocates .o object files for the purposes of loading and executing in a running image. Relocation to addresses in external shared libraries is dangerous, as GCL allows the user to save the running image and re-execute later, at which time the function could be in a different place. Function calls which can be manipulated at the C level are therefore redirected through pointers which are reset at image startup. _mcount cannot be treated as such, as there is no C source footprint to the call. I've tried redirecting the address to a mcount_wrapper internal to GCL, but this appears to cause corruption on s390 and powerpc alone. Using the external libc address functions properly on these platforms (at least until image save and restart). We have an analogous problem on alpha with the __divq and __remq calls inserted by the compiler directly into the .S or .o output.
Is there a safe way to wrap these calls? If not, is there a generic way to instruct gcc not to insert such or otherwise workaround the problem? Obviously this would at a minimum entail omitting -pg. Take care, -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
