1Prerequisite | ETRecord - ExecuTorch Record 2=========================================== 3 4Overview 5-------- 6 7``ETRecord`` is intended to be the debug artifact that is generated by 8users ahead of time (when they export their model to run on ExecuTorch). 9To draw a rough equivalent to conventional software development, 10``ETRecord`` can be considered as the binary built with debug symbols 11that is used for debugging in GNU Debugger (gdb). It is expected that 12the user will supply this to the ExecuTorch Developer Tools in order for 13them to debug and visualize their model. 14 15``ETRecord`` contains numerous components such as: 16 17* Edge dialect graph with debug handles 18* Delegate debug handle maps 19 20The ``ETRecord`` object itself is intended to be opaque to users and they should not access any components inside it directly. 21It should be provided to the `Inspector API <model-inspector.html>`__ to link back performance and debug data sourced from the runtime back to the Python source code. 22 23Generating an ``ETRecord`` 24-------------------------- 25 26The user should use the following API to generate an ``ETRecord`` file. They 27will be expected to provide the Edge Dialect program (returned by the call to ``to_edge()``), 28the ExecuTorch program (returned by the call to ``to_executorch()``), and optional models that 29they are interested in working with via our tooling. 30 31.. warning:: 32 Users should do a deepcopy of the output of ``to_edge()`` and pass in the deepcopy to the ``generate_etrecord`` API. This is needed because the subsequent call, ``to_executorch()``, does an in-place mutation and will lose debug data in the process. 33 34.. currentmodule:: executorch.devtools.etrecord._etrecord 35.. autofunction:: generate_etrecord 36 37Using an ``ETRecord`` 38--------------------- 39 40Pass the ``ETRecord`` as an optional argument into the `Inspector API <model-inspector.html>`__ to access this data and do post-run analysis. 41