how hard is it to rewrite code in a .beam file?

[Matthias Lang]

Mostly answering my own question:

Hacking .beam files isn't very hard, getting into it takes a few
hours.  beam_disasm.erl, beam_asm.erl, compile.erl and beam_lib.erl
are useful references.

For me, the spanner in the works was ordinary additions, i.e.  the
.beam made by R10B contains:

  {m_plus,[{f,0},{x,0},{i,2},{x,0}]},      % erlang code: X + 2

but m_plus is long gone, R13B generates this instead:

  {gc_bif2,[{f,0},{u,1},{u,0},{x,0},{i,2},{x,0}]},

I don't completely understand the arguments lists. In the first case,
the arguments are

  {m_plus,[{f,0},   %% what's this?
           {x,0},   %% source register
           {i,2},   %% source immediate integer value 2
           {x,0},   %% destination register

So I don't know exactly what {f,0} and {u,1} and {u,0} are. I think
they tell beam which function I want and supply some liveness
information, whatever exactly that is. Clues, please?

Matt

----------------------------------------------------------------------
On Friday, August 27, Matthias Lang wrote:
> Hi,
> 
> I'd appreciate some wisdom about writing a .beam -> .beam transform
> which lets me load a few known (i.e. not every possible) .beam files
> compiled with R10B into an R13B04 VM. 
> 
> I've looked at beam_load.c and beam_disasm.erl, they seem like
> reasonable starting points. Anything else I should look at? Am
> I doomed to fail, or do I have a sporting chance? Kostis? Björn? Tony?
> 
> ---
> 
> I want to do this because upgrades on my embedded systems work roughly
> like this:
> 
>     1. Unpack a release file
>     2. Run gth_install.beam on the freshly unpacked release
>     3. Reboot
> 
> This works fine until someone tries to downgrade from a modern release,
> which uses R13B04, to an old release, which uses R10B:
> 
>   =ERROR REPORT==== 27-Aug-2010::15:07:03 ===
>   beam/beam_load.c(1730): Error loading function gth_install:make_nand_symlinks/1: op m_plus p y i r:
>   please re-compile this module with an R13B04 compiler 
> 
> I should have heeded warnings about efforts being made to preserve .beam
> compatibility for two major OTP versions only. But I didn't. Duh.
> 
> I have a few ideas about how to extricate myself from this,
> e.g. running multiple VMs at the same time or providing new versions
> of the old .beams, but the .beam->.beam seems fun and neat, given
> that I only have to make it work for a handful of versions of one module.
> 
> Matt