[erlang-questions] has anyone cross compiled HiPE?

[Matthias Lang]

I have a partial answer to my own question #2 (I answered #1 earlier).

Quoting myself:
>       Second, I need to compile my Erlang code to ARM native code.
>       I can't see an option to do that, i.e. if I use c(my_module, native)
>       on my AMD64, I get an extra chunk in the .beam file called
>       "HA64". I'm guessing that's AMD-64 specific code. So I need some
>       way to tell HiPE that I want it to make ARM native code.
>
>       (I've looked at TFM, specifically the HiPE App and the compile
>       module page. Nothing there about generating code for specific
>       targets. Maybe there's another page I've missed.)

HiPE actually has quite a bit of documentation, it's just not in the
usual spot, it's edoc-style, in the source, e.g. in hipe.erl.

In short, you can ask HiPE to generate ARM code even when running on
an x86, like this:

   c(example_module, [native, {hipe, {target, arm}}]).

this makes a .beam file with ARM native code in it. Great...except
that the ARM VM refuses to load that code. So far, I haven't gotten
around that, but it can't be that hard. Rest of post is about what
I've done so far.

---

In theory, there shouldn't be a problem here. Hipe is just Erlang code
which makes code for some CPU. That Erlang code should generate the
same thing no matter what CPU it happens to be running on.

In practice, HiPE makes different things depending on what system it's
running on. For starters, the generated code has a signature in it
which identifies the generating system. The loading system checks that
signature and refuses to load if the signatures don't match. This
signature is called HIPE_SYSTEM_CRC.

Right, no problem then. If I use the same hipe compiler .beams as are
running on the ARM system, the HIPE_SYSTEM_CRC macro will have the
right magic value in it. I can tell the code loader on my x86 system
to use that code:

    code:del_path(hipe).
    code:add_path("/home/matthias/gth3/rootfs/packages/erlang/otp_src_R15B/lib/hipe/ebin").

but the resulting .beams _still_ have the wrong signature in them. It
happens because the signature generation also throws in information
from 'hipe_bifs', which is C code. Bummer.

Maybe the signature is the only piece of information which leaks out
from the C code. Quick hack: disable the signature check. And, presto,
it works for simple code. For more complex code, it segfaults. There
must be something more to this.

To be continued in a week or two, I'm out of time for now.

Matt