# beam_lib

### MODULE

beam_lib

### MODULE SUMMARY

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"), and `atoms` ("Atom").

The syntax of the compound term (`ChunkData`) is as follows:

- `ChunkData = {ChunkId, binary()} | {abstract_code, AbstractCode} | {attributes, [{Attribute, [AttributeValue]}]} | {compile_info, [{InfoKey, [InfoValue]}]} | {exports, [{Function, Arity}]} | {labeled_exports, [{Function, Arity, Label}]} | {imports, [{Module, Function, Arity}]} | {indexed_imports, [{Index, Module, Function, Arity}]} | {locals, [{Function, Arity}]}]} | {labeled_locals, [{Function, Arity, Label}]}]} | {atoms, [{integer(), atom()}]}`
- `ChunkRef = ChunkId | ChunkName`
- `ChunkName = abstract_code | attributes | compile_info | exports | labeled_exports | imports | indexed_imports | locals | labeled_locals | atoms`
- `ChunkId = string()`
- `AbstractCode = {AbstVersion, forms()} | no_abstract_code`
- `AbstVersion = atom()`
- `Attribute = atom()`
- `AttributeValue = term()`
- `Module = Function = atom()`
- `Arity = integer() >= 0`
- `Label = integer() >= 0`

The list of attributes is sorted on `Attribute`, and each attribute name occurs once in the list. The attribute values occur in the same order as on the file. The lists of functions are also sorted. 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.

Each of the functions described below accept either a filename or a binary containing a beam module.

### ENCRYPTED ABSTRACT CODE

The abstract code can be encrypted in order to keep the source code secret, but still be able to use tools such as Xref or Debugger. See compile for how to encrypt the abstract code.

To enable tools to use the abstract code, the key must be made available for `beam_lib`. There are two ways to provide the key.

Use the function crypto_key_fun/1 to register a fun that will be called whenever `beam_lib` needs to decrypt the abstract code.

Store the key in a text file named `.erlang.crypt` located in either the current directory or the home directory for the current user. `beam_lib` will search for and read the `.erlang.crypt` file if no crypto fun has been registered using crypto_key_fun/1. If the file exists and contains a key, `beam_lib` will implicitly create a crypto key fun and register it.

The `.erlang.crypt` file should define a single list. The elements of the list should be tuples looking like this:

    {debug_info, Mode, Module, Key}

`Mode` is the type of key; currently, the only allowed value 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 a non-empty list.

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^"}].

| Do NOT use any of the keys in these examples. Use your own keys.

### EXPORTS

`chunks(FileNameOrBinary, [ChunkRef]) -> {ok, {Module, [ChunkData]}} | {error, Module, Reason}`

Types:

`FileNameOrBinary = string() | atom() | binary()`
`Reason = {unknown_chunk, FileName, atom()} | {key_missing_or_invalid, FileName, abstract_code} | - see info/1 -`

The `chunks/2` function reads chunk data for selected chunks. The order of the returned list of chunk data is determined by the order of the list of chunks references; if each chunk data were replaced by the tag, the result would be the given list.

`version(FileNameOrBinary) -> {ok, {Module, Version}} | {error, Module, Reason}`

Types:

`FileNameOrBinary = string() | atom() | binary()`
`Version = [term()]`
`Reason = - see chunks/2 -`

The `version/1` function returns the module version(s) found in a BEAM file.

`info(FileNameOrBinary) -> [SourceRef, {module, Module}, {chunks, [ChunkInfo]}] | {error, Module, Reason}`

Types:

`FileName = string() | atom()`
`FileNameOrBinary = FileName | binary()`
`SourceRef = {file, FileName} | {binary, binary()}`
`ChunkInfo = {ChunkId, StartPosition, Size}`
`StartPosition = integer() > 0`
`Size = integer() >= 0`
`Reason = {chunk_too_big, FileName, ChunkId, ChunkSize, FileSize} | {invalid_beam_file, FileName, FilePosition} | {invalid_chunk, FileName, ChunkId} | {missing_chunk, FileName, ChunkId} | {not_a_beam_file, FileName} | {file_error, FileName, FileError}`

The `info/1` function extracts some information about a BEAM file: the file name, the module name, and for each chunk the identifier as well as the position and size in bytes of the chunk data.

`cmp(FileNameOrBinary, FileNameOrBinary) -> ok | {error, Module, Reason}`

Types:

`FileName = string() | atom()`
`FileNameOrBinary = FileName | binary()`
`Reason = {modules_different, Module, Module} | {chunks_different, ChunkId} | - see info/1 -`

The `cmp/2` function compares the contents of two BEAM files. If the module names are the same, and the chunks with the identifiers "Code", "ExpT", "ImpT", "StrT", and "Atom" have the same contents in both files, `ok` is returned. Otherwise an error message is returned.

`cmp_dirs(Directory1, Directory2) -> {Only1, Only2, Different} | {error, Module, Reason}`

Types:

`Directory1 = Directory2 = string() | atom()`
`Different = [{FileName1, FileName2}]`
`Only1 = Only2 = [FileName]`
`FileName = FileName1 = FileName2 = string()`
`Reason = - see info/1 -`

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 `Directory1` (`Directory2`) 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 `Directory1` (`Directory2`).

`diff_dirs(Directory1, Directory2) -> ok | {error, Module, Reason}`

Types:

`Directory1 = Directory2 = string() | atom()`
`Reason = - see info/1 -`

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(FileNameOrBinary) -> {ok, {Module, FileNameOrBinary}} | {error, Module, Reason}`

Types:

`FileName = string() | atom()`
`FileNameOrBinary = FileName | binary()`
`Reason = - see info/1 -`

The `strip/1` function removes all chunks from a BEAM file except those needed by the loader. In particular, the abstract code is removed. The module name found in the file and the file name, possibly with the ".beam" extension added, are returned.

`strip_files(Files) -> {ok, [{Module, FileNameOrBinary]}} | {error, Module, Reason}`

Types:

`Files = [FileNameOrBinary]`
`FileName = string() | atom()`
`FileNameOrBinary = FileName | binary()`
`Reason = - see info/1 -`

The `strip_files/1` function removes all chunks except those needed by the loader from BEAM files. In particular, the abstract code is removed. The returned list contains one element for each given file name, ordered as the given list. The list element is a pair of the module name found in the file and the file name, the latter possibly with the ".beam" extension added.

`strip_release(Directory) -> {ok, [{Module, FileName]}} | {error, Module, Reason}`

Types:

`Directory = string() | atom()`
`FileName = string()`
`Reason = - see info/1 -`

The `strip_release/1` function removes all chunks except those needed by the loader from the BEAM files of a release. `Directory` 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())`. The returned list contains module names and file names of stripped files.

`format_error(Error) -> character_list()`

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 `format_error/1` in the `file` module is called.

`crypto_key_fun(CryptoKeyFun) -> ok | {error, Reason}`

Types:

`CryptoKeyFun = fun()`
`Reason = badfun | exists | term()`

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 will be held in a process that will be started by `crypto_key_fun/1`.)

If there already is a fun registered when attempting to register a fun, `{error,exists}` will be returned.

The fun will be called with one argument. The fun must be prepared to be called with the following arguments:

- `init`: Called when the fun is registered, in the process that holds the fun. Here the crypto key fun can do any necessary initializations. Allowed return values: `ok`, `{ok,NewCryptoKeyFun}` (`NewCryptoKeyFun` will be registered instead of `CryptoKeyFun`), or `{error,Reason}` (the registration will be aborted and `crypto_key_fun/1` will return `{error,Reason}`, where `Reason` can be any term).
- `{debug_info, Mode, Module, Filename}`: Called when the key is needed for module `Module` in file `Filename`. `Mode` describes the method of encryption; currently the only allowed value is `des3_cbc`. The fun should return the key as list of characters or fail if there is no key available.
- `clear`: Called just before the fun is unregistered. Do any needed cleanup here. The return value is not important, but will be passed back to the caller of `clear_crypto_key_fun/0`.

`clear_crypto_key_fun() -> {ok, Result}`

Types:

`Result = undefined | term()`

Unregisters the crypto key fun and terminates the process that was 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 the crypto key fun called with the argument `clear`.

### AUTHORS

Hans Bolinder - support@erlang.ericsson.se

stdlib 1.13.8
Copyright © 1991-2005 Ericsson AB