[erlang-questions] Proposal: a new Dbgi BEAM chunk

José Valim jose.valim@REDACTED
Mon Mar 13 13:55:21 CET 2017


Many tools in the Erlang ecosystem expect the Erlang Abstract Code chunk to
exist or, if it doesn't exist, it automatically generates one from the
source code, if it can find the respective Erlang source.

This restricts the use of the existing tooling to only some languages and
leads to code duplication in different tools (such as dialyzer, debuger,
cover, etc) as each tool includes their own implemention of loading
abstract code from beams, fetching it from source as well as converting the
abstract code to other formats.

To partially solve this issue for languages that compile directly to Core,
such as LFE, I have earlier proposed a chunk that stores Core AST. However,
even if we add such chunk, I can foresee the following problems:

  * Storing the Core AST chunk still does not include the ability of
retrieving the AST on the fly in case the chunk is not available for
whatever reason

  * Adding a new chunk could potentially make the situation worse because
tools in the future may work directly on those new chunks, forcing
compilers to add both Erlang Abstract Format and Code AST chunks to the
.beam file. Futhermore, it is expected that languages may want to store
their own AST as well, which will lead to further increase on the .beam
file size

Therefore we need a mechanism to store abstract code on .beam such that:

  * The abstract code is stored once but can be retrieved in different
formats, as supported by the initial language (where the initial language
is erlang, core, lfe, elixir, alpaca, etc)

  * If the abstract code is omitted, we should still provide the ability to
retrieve it from source if desired, regardless of the initial language

I have written a proposal which aims to unify how abstract code, or
generally speaking, debug information is stored on `.beam` by introducing a
new chunk, called "Dbgi" which aims to replace the current "Absc" chunk.
The proposal is backwards compatible and solves the problems outlined above.

The full proposal alongside a prototype can be found on GitHub:
https://github.com/erlang/otp/pull/1367

Feedback is welcome!


*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170313/5ec7c0cc/attachment.htm>


More information about the erlang-questions mailing list