[m-dev.] Trying to add shared objects support for ARM

Julien Fischer juliensf at cs.mu.OZ.AU
Tue Dec 6 15:35:30 AEDT 2005

On Mon, 5 Dec 2005, Sergey Khorev wrote:

> Thanks for inclusion ARM support into CVS.

Thanks for contributing it!

> Currently, I've compiled and
> tested asm_fast.gc, hlc.gc, asm_fast.gc.tr, asm_fast.gc.tr.debug,
> asm_fast.gc.tr.decldebug, asm_fast.gc.prof, asm_fast.gc.memprof grades.
> The outstanding test failures mentioned in my previous emails had their
> roots in gcc optimiser bug rather than in Mercury or system I/O quirks!
> Insipired with this fact I'm trying to add support for shared libraries. It
> seems that platform-specific hacks in runtime/mercury_goto.h are not as
> fearful as they appeared for me at first sight.

The hacks in runtime/mercury_goto.h are only necessary for the asm_fast*
grades. You may want to try getting shared libraries to work with hlc.gc,
it should just be a matter of enabling them in the configure script.

>  At least I can literally
> translate them to ARM assemly language without much knowledge about it or
> ELF :) I believe there is a chance this will work after series of attempts.
> BUT: comment in runtime/mercury_goto.h states
>   (I don't understand the details exactly, this code is
>    basically copied from the output of `gcc -fpic -S')
> I wonder what file should I compile with -fpic -S to see manipulations with

I'm not sure; presumably something that uses shared libraries.

> Doesn't this really mean "compile with -fpic and then
> disassemly"? ;)

It means compile with -fpic and then don't assemble but write the assembly
code to a file but the effect would be more or less the same.


mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list