Loading refers instantiating the binary module in some fashion, usually copy all or some of the binary module into memory and then linking the module with other components.
In most architectures, it is the base FLASH code that is the primary component that the binary module must link with because that is where the RTOS and primary tasks reside.
Program modules can then be executed after they have been loaded.
</p>
<p>
<b>Binary Formats</b>.
The binary loader provides generic support for different binary formats.
It supports a <i>registration interface</i> that allows the number of support binary formats to be loaded at run time.
Each binary format provides a common, interface for use by the binary loader.
When asked to load a binary, the binary loader will query each registered binary format, providing it with the path of the binary object to be loaded.
The binary loader will stop when first binary format the recognizes the binary object and successfully loads it or when all registered binary formats have attempt loading the binary object and failed.
</p>
<p>
At present, the following binary formats are support by NuttX:
</p>
<ul>
<li>
<b>ELF</b>.
Standard ELF formatted files.
</li>
<li>
<b>NXFLAT</b>.
NuttX NXFLAT formatted files.
More information about the NXFLAT binary format can be found in the
The generic binary loader logic does not care what it is that it being loaded. It could load an executable program or a library.
There are no strict rules, but a library will tend to export symbols and a program will tend to import symbols: The program will use the symbols exported by the library.
In the NuttX source code, the short name <code>binfmt</code> is used to refer to the NuttX binary loader.
This is the name of the directory containing the binary loader and the name of the header files and variables used by the binary loader.
</p>
<p>
The name <code>binfmt</code> is the same name used by the Linux binary loader.
However, the NuttX binary loader is an independent development and shares nothing with the Linux binary loader other the same name and the same basic functionality.
It returns either <code>OK</code> (0) meaning that the binary object was loaded successfully, or a negated <code>errno</code> indicating why the object was not loaded.
The type <code>struct binary_s</code> is use both to (2) describe the binary object to be loaded, and if successfully loaded, (2) to provide information about where and how the binary object was loaded.
That structure is shown below:
</p>
<ul><pre>
struct symtab_s;
struct binary_s
{
/* Information provided to the loader to load and bind a module */
<sup>1</sup>The <code>filename</code> must be the full, absolute path to the file to be executed unless <code>CONFIG_BINFMT_EXEPATH</code> is defined.
In that case, <code>filename</code> may be a relative path;
a set of candidate absolute paths will be generated using the <code>PATH</code> environment variable and <ahref="#load_module"><code>load_module()</code></a> will attempt to load each file that is found at those absolute paths.
This is a NuttX internal function so it follows the convention that 0 (<code>OK</code>) is returned on success and a negated <code>errno</code> is returned on failure.
int unregister_binfmt(FAR struct binfmt_s *binfmt);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Register a loader for a binary format.
</ul>
<p><b>Returned Value:</b></p>
<ul>
This is a NuttX internal function so it follows the convention that 0 (<code>OK</code>) is returned on success and a negated <code>errno</code> is returned on failure.
Load a module into memory, bind it to an exported symbol take, and prep the module for execution.
</p>
<p>
<code>load_module()</code> will use the <code>filename</code> field in the <ahref="#binfmtdata"><code>struct binary_s</code></a> in order to locate the module to be loaded from the file system.
The <code>filename</code> must be the full, absolute path to the file to be executed unless <code>CONFIG_BINFMT_EXEPATH</code> is defined.
In that case, <code>filename</code> may be a relative path;
a set of candidate absolute paths will be generated using the <code>PATH</code> environment variable and <code>load_module()</code> will attempt to load each file that is found at those absolute paths.
If the module has been started (via <code>exec_module()</code>) and has not exited, calling this will be fatal.
</p>
<p>
However, this function must be called after the module exist.
How this is done is up to your logic.
Perhaps you register it to be called by <code>on_exit()</code>?
</ul>
<p><b>Returned Value:</b></p>
<ul>
This is a NuttX internal function so it follows the convention that 0 (<code>OK</code>) is returned on success and a negated <code>errno</code> is returned on failure.
Initialize for the traversal of each value in the <code>PATH</code> variable.
The usage is sequence is as follows:
</p>
<ol>
<li>
Call <code>exepath_init()</code> to initialize for the traversal.
<code>exepath_init()</code> will return an opaque handle that can then be provided to <code>exepath_next()</code> and <code>exepath_release()</code>.
</li>
<li>
Call <code>exepath_next()</code> repeatedly to examine every file that lies in the directories of the <code>PATH</code> variable.
</li>
<li>
Call <code>exepath_release()</code> to free resources set aside by <code>exepath_init()</code>.
</li>
</ol>
</ul>
<p><b>Input Parameters:</b><i>None</i></p>
<p><b>Returned Value:</b></p>
<ul>
On success, <code>exepath_init()</code> return a non-<code>NULL</code>, opaque handle that may subsequently be used in calls to <code>exepath_next()</code> and <code>exepath_release()</code>.
On error, a <code>NULL</code> handle value will be returned.
The most likely cause of an error would be that the there is no value associated with the <code>PATH</code> variable.
FAR char *exepath_next(EXEPATH_HANDLE handle, FAR const char *relpath);
#endif
</pre></ul>
<p><b>Description:</b></p>
<ul>
Traverse all possible values in the <code>PATH</code> variable in attempt to find the full path to an executable file when only a relative path is provided.
</ul>
<p><b>Input Parameters:</b></p>
<ul>
<li><code>handle</code>: The handle value returned by <code>exepath_init()</code>.</li>
<li><code>relpath</code>: The relative path to the file to be found.</li>
</ul>
<p><b>Returned Value:</b></p>
<ul>
<p>
On success, a non-<code>NULL</code> pointer to a null-terminated string is provided.
This is the full path to a file that exists in the file system.
This function will verify that the file exists (but will not verify that it is marked executable).
</p>
<p>
NOTE: The string pointer return in the success case points to allocated memory.
<code>NULL</code is returned if no path is found to any file with the provided <code>relpath</colde> from any absolute path in the <code>PATH</code> variable.
In this case, there is no point in calling <code>exepath_next()</code> further; <code>exepath_release()</code> must be called to release resources set aside by <code>expath_init()</code>.
Release all resources set aside by <code>exepath_init</code> when the handle value was created.
The handle value is invalid on return from this function.
Attempts to all <code>exepath_next()</code> or <code>exepath_release()</code> with such a <i>stale</i> handle will result in undefined (i.e., not good) behavior.
</ul>
<p><b>Input Parameters:</b></p>
<ul>
<li><code>handle</code>: The handle value returned by <code>exepath_init()</code>.</li>
The name is a string that identifies a symbol, and the value is an address in memory where the symbol of that name has been positioned.
In most NuttX architectures symbol tables are required, as a minimum, in order to dynamically link the loaded binary object with the base code on FLASH.
Since the binary object was separately built and separately linked, these symbols will appear as <i>undefined</i> symbols in the binary object.
The binary loader will use the symbol table to look up the symbol by its name and to provide the address associated with the symbol as needed to perform the dynamic linking of the binary object to the base FLASH code.
