Provided by: erlang-manpages_16.b.3-dfsg-1ubuntu2.2_all 
NAME
beam_lib - An Interface To the BEAM File Format
DESCRIPTION
beam_lib provides an interface to files created by the BEAM compiler ("BEAM files"). The
format used, a variant of "EA IFF 1985" Standard for Interchange Format Files, divides
data into chunks.
Chunk data can be returned as binaries or as compound terms. Compound terms are returned
when chunks are referenced by names (atoms) rather than identifiers (strings). The names
recognized and the corresponding identifiers are:
* abstract_code ("Abst")
* attributes ("Attr")
* compile_info ("CInf")
* exports ("ExpT")
* labeled_exports ("ExpT")
* imports ("ImpT")
* indexed_imports ("ImpT")
* locals ("LocT")
* labeled_locals ("LocT")
* atoms ("Atom")
DEBUG INFORMATION/ABSTRACT CODE
The option debug_info can be given to the compiler (see compile(3erl)) in order to have
debug information in the form of abstract code (see The Abstract Format in ERTS User's
Guide) stored in the abstract_code chunk. Tools such as Debugger and Xref require the
debug information to be included.
Warning:
Source code can be reconstructed from the debug information. Use encrypted debug
information (see below) to prevent this.
The debug information can also be removed from BEAM files using strip/1, strip_files/1
and/or strip_release/1.
Reconstructing source code
Here is an example of how to reconstruct source code from the debug information in a BEAM
file Beam:
{ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).
Encrypted debug information
The debug information can be encrypted in order to keep the source code secret, but still
being able to use tools such as Xref or Debugger.
To use encrypted debug information, a key must be provided to the compiler and beam_lib.
The key is given as a string and it is recommended that it contains at least 32 characters
and that both upper and lower case letters as well as digits and special characters are
used.
The default type -- and currently the only type -- of crypto algorithm is des3_cbc, three
rounds of DES. The key string will be scrambled using erlang:md5/1 to generate the actual
keys used for des3_cbc.
Note:
As far as we know by the time of writing, it is infeasible to break des3_cbc encryption
without any knowledge of the key. Therefore, as long as the key is kept safe and is
unguessable, the encrypted debug information should be safe from intruders.
There are two ways to provide the key:
* Use the compiler option {debug_info,Key}, see compile(3erl), and the function
crypto_key_fun/1 to register a fun which returns the key whenever beam_lib needs to
decrypt the debug information.
If no such fun is registered, beam_lib will instead search for a .erlang.crypt file,
see below.
* Store the key in a text file named .erlang.crypt.
In this case, the compiler option encrypt_debug_info can be used, see compile(3erl).
.erlang.crypt
beam_lib searches for .erlang.crypt in the current directory and then the home directory
for the current user. If the file is found and contains a key, beam_lib will implicitly
create a crypto key fun and register it.
The .erlang.crypt file should contain a single list of tuples:
{debug_info, Mode, Module, Key}
Mode is the type of crypto algorithm; currently, the only allowed value thus is des3_cbc.
Module is either an atom, in which case Key will only be used for the module Module, or
[], in which case Key will be used for all modules. Key is the non-empty key string.
The Key in the first tuple where both Mode and Module matches will be used.
Here is an example of an .erlang.crypt file that returns the same key for all modules:
[{debug_info, des3_cbc, [], "%>7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].
And here is a slightly more complicated example of an .erlang.crypt which provides one key
for the module t, and another key for all other modules:
[{debug_info, des3_cbc, t, "My KEY"},
{debug_info, des3_cbc, [], "%>7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].
Note:
Do not use any of the keys in these examples. Use your own keys.
DATA TYPES
beam() = module() | file:filename() | binary()
Each of the functions described below accept either the module name, the filename,
or a binary containing the beam module.
chunkdata() = {chunkid(), dataB()}
| {abstract_code, abst_code()}
| {attributes, [attrib_entry()]}
| {compile_info, [compinfo_entry()]}
| {exports, [{atom(), arity()}]}
| {labeled_exports, [labeled_entry()]}
| {imports, [mfa()]}
| {indexed_imports,
[{index(),
module(),
Function :: atom(),
arity()}]}
| {locals, [{atom(), arity()}]}
| {labeled_locals, [labeled_entry()]}
| {atoms, [{integer(), atom()}]}
The list of attributes is sorted on Attribute (in attrib_entry()), and each
attribute name occurs once in the list. The attribute values occur in the same
order as in the file. The lists of functions are also sorted.
chunkid() = nonempty_string()
"Abst" | "Attr" | "CInf" | "ExpT" | "ImpT" | "LocT" | "Atom"
dataB() = binary()
abst_code() = {AbstVersion :: atom(), forms()}
| no_abstract_code
It is not checked that the forms conform to the abstract format indicated by
AbstVersion. no_abstract_code means that the "Abst" chunk is present, but empty.
forms() = [erl_parse:abstract_form()]
compinfo_entry() = {InfoKey :: atom(), term()}
attrib_entry() =
{Attribute :: atom(), [AttributeValue :: term()]}
labeled_entry() = {Function :: atom(), arity(), label()}
index() = integer() >= 0
label() = integer()
chunkref() = chunkname() | chunkid()
chunkname() = abstract_code
| attributes
| compile_info
| exports
| labeled_exports
| imports
| indexed_imports
| locals
| labeled_locals
| atoms
chnk_rsn() = {unknown_chunk, file:filename(), atom()}
| {key_missing_or_invalid,
file:filename(),
abstract_code}
| info_rsn()
info_rsn() = {chunk_too_big,
file:filename(),
chunkid(),
ChunkSize :: integer() >= 0,
FileSize :: integer() >= 0}
| {invalid_beam_file,
file:filename(),
Position :: integer() >= 0}
| {invalid_chunk, file:filename(), chunkid()}
| {missing_chunk, file:filename(), chunkid()}
| {not_a_beam_file, file:filename()}
| {file_error, file:filename(), file:posix()}
EXPORTS
chunks(Beam, ChunkRefs) ->
{ok, {module(), [chunkdata()]}} |
{error, beam_lib, chnk_rsn()}
Types:
Beam = beam()
ChunkRefs = [chunkref()]
Reads chunk data for selected chunks refs. The order of the returned list of chunk
data is determined by the order of the list of chunks references.
chunks(Beam, ChunkRefs, Options) ->
{ok, {module(), [ChunkResult]}} |
{error, beam_lib, chnk_rsn()}
Types:
Beam = beam()
ChunkRefs = [chunkref()]
Options = [allow_missing_chunks]
ChunkResult = chunkdata()
| {ChunkRef :: chunkref(), missing_chunk}
Reads chunk data for selected chunks refs. The order of the returned list of chunk
data is determined by the order of the list of chunks references.
By default, if any requested chunk is missing in Beam, an error tuple is returned.
However, if the option allow_missing_chunks has been given, a result will be
returned even if chunks are missing. In the result list, any missing chunks will be
represented as {ChunkRef,missing_chunk}. Note, however, that if the "Atom" chunk if
missing, that is considered a fatal error and the return value will be an error
tuple.
version(Beam) ->
{ok, {module(), [Version :: term()]}} |
{error, beam_lib, chnk_rsn()}
Types:
Beam = beam()
Returns the module version(s). A version is defined by the module attribute
-vsn(Vsn). If this attribute is not specified, the version defaults to the checksum
of the module. Note that if the version Vsn is not a list, it is made into one,
that is {ok,{Module,[Vsn]}} is returned. If there are several -vsn module
attributes, the result is the concatenated list of versions. Examples:
1> beam_lib:version(a). % -vsn(1).
{ok,{a,[1]}}
2> beam_lib:version(b). % -vsn([1]).
{ok,{b,[1]}}
3> beam_lib:version(c). % -vsn([1]). -vsn(2).
{ok,{c,[1,2]}}
4> beam_lib:version(d). % no -vsn attribute
{ok,{d,[275613208176997377698094100858909383631]}}
md5(Beam) -> {ok, {module(), MD5}} | {error, beam_lib, chnk_rsn()}
Types:
Beam = beam()
MD5 = binary()
Calculates an MD5 redundancy check for the code of the module (compilation date and
other attributes are not included).
info(Beam) -> [InfoPair] | {error, beam_lib, info_rsn()}
Types:
Beam = beam()
InfoPair = {file, Filename :: file:filename()}
| {binary, Binary :: binary()}
| {module, Module :: module()}
| {chunks,
[{ChunkId :: chunkid(),
Pos :: integer() >= 0,
Size :: integer() >= 0}]}
Returns a list containing some information about a BEAM file as tuples {Item,
Info}:
{file, Filename} | {binary, Binary}:
The name (string) of the BEAM file, or the binary from which the information
was extracted.
{module, Module}:
The name (atom) of the module.
{chunks, [{ChunkId, Pos, Size}]}:
For each chunk, the identifier (string) and the position and size of the chunk
data, in bytes.
cmp(Beam1, Beam2) -> ok | {error, beam_lib, cmp_rsn()}
Types:
Beam1 = Beam2 = beam()
cmp_rsn() = {modules_different, module(), module()}
| {chunks_different, chunkid()}
| different_chunks
| info_rsn()
Compares the contents of two BEAM files. If the module names are the same, and all
chunks except for the "CInf" chunk (the chunk containing the compilation
information which is returned by Module:module_info(compile)) have the same
contents in both files, ok is returned. Otherwise an error message is returned.
cmp_dirs(Dir1, Dir2) ->
{Only1, Only2, Different} | {error, beam_lib, Reason}
Types:
Dir1 = Dir2 = atom() | file:filename()
Only1 = Only2 = [file:filename()]
Different =
[{Filename1 :: file:filename(), Filename2 :: file:filename()}]
Reason = {not_a_directory, term()} | info_rsn()
The cmp_dirs/2 function compares the BEAM files in two directories. Only files with
extension ".beam" are compared. BEAM files that exist in directory Dir1 (Dir2) only
are returned in Only1 (Only2). BEAM files that exist on both directories but are
considered different by cmp/2 are returned as pairs {Filename1, Filename2} where
Filename1 (Filename2) exists in directory Dir1 (Dir2).
diff_dirs(Dir1, Dir2) -> ok | {error, beam_lib, Reason}
Types:
Dir1 = Dir2 = atom() | file:filename()
Reason = {not_a_directory, term()} | info_rsn()
The diff_dirs/2 function compares the BEAM files in two directories the way
cmp_dirs/2 does, but names of files that exist in only one directory or are
different are presented on standard output.
strip(Beam1) ->
{ok, {module(), Beam2}} | {error, beam_lib, info_rsn()}
Types:
Beam1 = Beam2 = beam()
The strip/1 function removes all chunks from a BEAM file except those needed by the
loader. In particular, the debug information (abstract_code chunk) is removed.
strip_files(Files) ->
{ok, [{module(), Beam}]} |
{error, beam_lib, info_rsn()}
Types:
Files = [beam()]
Beam = beam()
The strip_files/1 function removes all chunks except those needed by the loader
from BEAM files. In particular, the debug information (abstract_code chunk) is
removed. The returned list contains one element for each given file name, in the
same order as in Files.
strip_release(Dir) ->
{ok, [{module(), file:filename()}]} |
{error, beam_lib, Reason}
Types:
Dir = atom() | file:filename()
Reason = {not_a_directory, term()} | info_rsn()
The strip_release/1 function removes all chunks except those needed by the loader
from the BEAM files of a release. Dir should be the installation root directory.
For example, the current OTP release can be stripped with the call
beam_lib:strip_release(code:root_dir()).
format_error(Reason) -> io_lib:chars()
Types:
Reason = term()
Given the error returned by any function in this module, the function format_error
returns a descriptive string of the error in English. For file errors, the function
file:format_error(Posix) should be called.
crypto_key_fun(CryptoKeyFun) -> ok | {error, Reason}
Types:
CryptoKeyFun = crypto_fun()
Reason = badfun | exists | term()
crypto_fun() = fun((crypto_fun_arg()) -> term())
crypto_fun_arg() = init
| clear
| {debug_info,
mode(),
module(),
file:filename()}
mode() = des3_cbc
The crypto_key_fun/1 function registers a unary fun that will be called if beam_lib
needs to read an abstract_code chunk that has been encrypted. The fun is held in a
process that is started by the function.
If there already is a fun registered when attempting to register a fun, {error,
exists} is returned.
The fun must handle the following arguments:
CryptoKeyFun(init) -> ok | {ok, NewCryptoKeyFun} | {error, Term}
Called when the fun is registered, in the process that holds the fun. Here the
crypto key fun can do any necessary initializations. If {ok, NewCryptoKeyFun} is
returned then NewCryptoKeyFun will be registered instead of CryptoKeyFun. If
{error, Term} is returned, the registration is aborted and crypto_key_fun/1 returns
{error, Term} as well.
CryptoKeyFun({debug_info, Mode, Module, Filename}) -> Key
Called when the key is needed for the module Module in the file named Filename.
Mode is the type of crypto algorithm; currently, the only possible value thus is
des3_cbc. The call should fail (raise an exception) if there is no key available.
CryptoKeyFun(clear) -> term()
Called before the fun is unregistered. Here any cleaning up can be done. The return
value is not important, but is passed back to the caller of clear_crypto_key_fun/0
as part of its return value.
clear_crypto_key_fun() -> undefined | {ok, Result}
Types:
Result = undefined | term()
Unregisters the crypto key fun and terminates the process holding it, started by
crypto_key_fun/1.
The clear_crypto_key_fun/1 either returns {ok, undefined} if there was no crypto
key fun registered, or {ok, Term}, where Term is the return value from
CryptoKeyFun(clear), see crypto_key_fun/1.