ERL-1345: compiler module file method does not allow BEAM to be converted to asm

[OTP-Maintainer]

Original reporter: JIRAUSER16603
Affected version: OTP-23
Component: compiler
Migrated from: https://bugs.erlang.org/browse/ERL-1345

---

Unfortunately the module is not set correctly in compile.erl and is set to the atom "none" and there is no workaround (no_error_module_mismatch has no effect in this context), the only thing that would work is the native option which causes the module name to be set correctly:
{code:java}
c("beamfile", [from_beam,'S']).
{code}
yields in all cases
{code:java}
** Module name 'none' does not match file name '"beamfile"' **
{error,badfile}
{code}
Which is not ideal as it is relatively uncertain if there is any other straight forward method to generate recompilable asm code straight from BEAM.  The BEAM asm can be fetched easily and represented in a tree-like data structure variant, or even as an AST from the beam_lib as can the original erlang if the debug info included (which could then generate a .S file of course...)  From beam_lib format, manual conversion is possible but would be very tedious.  Of course "compile:forms" would be able to recompile either of those which also can require some clunky adapter code.

It seems from_beam is a new option and this use case scenario is simply not thought out or tried.  The native option being used to set the module name thereby seems to be a rather strange way to make some other functionality work.  The correct thing would be to always set the module name appropriately, and whatever other functionality from_beam is used for would have another variable set to indicate native.

Here is the offending code from lib/compiler/compile.erl:
{code:java}
read_beam_file(_Code, St) ->
    case file:read_file(St#compile.ifile) of {ok,Beam} ->
     Infile = St#compile.ifile,
     case no_native_compilation(Infile, St) of true ->
     {ok,none,St#compile{module=none}}; false ->
     Mod0 = filename:rootname(filename:basename(Infile)),
     Mod = list_to_atom(Mod0),
     {ok,Beam,St#compile{module=Mod,ofile=Infile}}
     end;
{code}

[OTP-Maintainer]

bjorn said:

The from_beam option is not new. Also note that is undocumented. It was specifically implemented a long time ago so that native code could be added to a BEAM file. It was never meant to be used in the way you want to use it, and setting the module name in read_beam_file/2 would not be sufficient to make it do what you want.

Producing .S fies from BEAM files is not mainstream use case. I would say that for anyone that has a need for .S file produced from a BEAM file, using beam_lib or beam_disasm is straight foward enough.

 

[OTP-Maintainer]

JIRAUSER16603 said:

Thanks for the info, I had no idea what the undocumented feature was for :).  Anyway, I can generate assembly with beam_disasm:file/1 however, this produces it in a format which is not recompilable.  It is in a tree structure more or less, similar to the AST.

It would be nice to know both how to recompile that tree structure as well as how to decompiler to proper .S.

I did figure out how to use compile:forms with from_asm however, it uses yet a different format.  This format is similar to the tree structure returned by beam_disasm:file/1 but with some of the tuples having elements removed from them.

I have always wanted the flexibility to be able to go between any asm format, any AST format, source code or BEAM formats easily and seamlessly.  I have dug pretty deep into some of the source to try to do this as cleanly as possible.  But it seems there are several cases where you end up having to write code that is hard to know if it will work in all situations.

[OTP-Maintainer]

bjorn said:

Yes, it is unfortunate that beam_disasm does not have exactly the same format as .S files. beam_disasm was introduced for the sake of HiPE and HiPE expects the disassembled BEAM files to have that exact format.