beam_lib(3erl)						     Erlang Module Definition						    beam_lib(3erl)

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  infor-
       mation 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 recom-
       mended 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 | Filename | binary()
	 Module = atom()
	 Filename = string() | atom()

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

       chunkdata() = {ChunkId, DataB} | {ChunkName, DataT}
	 ChunkId = chunkid()
	 DataB = binary()
	 {ChunkName, DataT} =
	       {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()}]}
	 AbstractCode = {AbstVersion, Forms} | no_abstract_code
	   AbstVersion = atom()
	 Attribute = atom()
	 AttributeValue = term()
	 Module = Function = atom()
	 Arity = int()
	 Label = int()

       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.

       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 in the file. The lists of functions are also sorted.

       chunkid() = "Abst" | "Attr" | "CInf"
		   | "ExpT" | "ImpT" | "LocT"
		   | "Atom"

       chunkname() = abstract_code | attributes | compile_info
		   | exports | labeled_exports
		   | imports | indexed_imports
		   | locals | labeled_locals
		   | atoms

       chunkref() = chunkname() | chunkid()

EXPORTS

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

	      Types  Beam = beam()
		     ChunkRef = chunkref()
		     Module = atom()
		     ChunkData = chunkdata()
		     Reason = {unknown_chunk, Filename, atom()}
		     | {key_missing_or_invalid, Filename, abstract_code}
		     | Reason1 -- see info/1
		     Filename = string()

	      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, [ChunkRef], [Option]) -> {ok, {Module, [ChunkResult]}} | {error, beam_lib, Reason}

	      Types  Beam = beam()
		     ChunkRef = chunkref()
		     Module = atom()
		     Option = allow_missing_chunks
		     ChunkResult = {chunkref(), ChunkContents} | {chunkref(), missing_chunk}
		     Reason = {missing_chunk, Filename, atom()}
		     | {key_missing_or_invalid, Filename, abstract_code}
		     | Reason1 -- see info/1
		     Filename = string()

	      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]}} | {error, beam_lib, Reason}

	      Types  Beam = beam()
		     Module = atom()
		     Version = term()
		     Reason -- see chunks/2

	      Returns the module version(s). A version is defined by the module attribute -vsn(Vsn) . If this attribute is not specified, the ver-
	      sion  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,{Mod-
	      ule,[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, Reason}

	      Types  Beam = beam()
		     Module = atom()
		     MD5 = binary()
		     Reason -- see chunks/2

	      Calculates an MD5 redundancy check for the code of the module (compilation date and other attributes are not included).

       info(Beam) -> [{Item, Info}] | {error, beam_lib, Reason1}

	      Types  Beam = beam()
		     Item, Info -- see below
		     Reason1 = {chunk_too_big, Filename, ChunkId, ChunkSize, FileSize}
		     | {invalid_beam_file, Filename, Pos}
		     | {invalid_chunk, Filename, ChunkId}
		     | {missing_chunk, Filename, ChunkId}
		     | {not_a_beam_file, Filename}
		     | {file_error, Filename, Posix}
		     Filename = string()
		     ChunkId = chunkid()
		     ChunkSize = FileSize = int()
		     Pos = int()
		     Posix = posix() -- see file(3erl)

	      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, Reason}

	      Types  Beam1 = Beam2 = beam()
		     Reason = {modules_different, Module1, Module2}
		     | {chunks_different, ChunkId}
		     | different_chunks
		     | Reason1 -- see info/1
		     Module1 = Module2 = atom()
		     ChunkId = chunkid()

	      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, Reason1}

	      Types  Dir1 = Dir2 = string() | atom()
		     Different = [{Filename1, Filename2}]
		     Only1 = Only2 = [Filename]
		     Filename = Filename1 = Filename2 = string()
		     Reason1 = {not_a_directory, term()} | -- 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 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, Reason1}

	      Types  Dir1 = Dir2 = string() | atom()
		     Reason1 = {not_a_directory, term()} | -- 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(Beam1) -> {ok, {Module, Beam2}} | {error, beam_lib, Reason1}

	      Types  Beam1 = Beam2 = beam()
		     Module = atom()
		     Reason1 -- see info/1

	      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, Beam2}]} | {error, beam_lib, Reason1}

	      Types  Files = [Beam1]
		     Beam1 = beam()
		     Module = atom()
		     Beam2 = beam()
		     Reason1 -- see info/1

	      The strip_files/1 function removes all chunks except those needed by the loader from BEAM files. In particular, the  debug  informa-
	      tion  (  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, Filename]}} | {error, beam_lib, Reason1}

	      Types  Dir = string() | atom()
		     Module = atom()
		     Filename = string()
		     Reason1 = {not_a_directory, term()} | -- see info/1

	      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) -> Chars

	      Types  Reason -- see other functions
		     Chars = [char() | Chars]

	      Given the error returned by any function in this module, the function format_error returns a descriptive string of the error in Eng-
	      lish. For file errors, the function file:format_error(Posix) should be called.

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

	      Types  CryptoKeyFun = fun() -- see below
		     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 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() -> {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 .

Ericsson AB							   stdlib 1.17.3						    beam_lib(3erl)