1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
|
<html>
<head>
<title>NuttX Binary Loader</title>
</head>
<body background="backgd.gif">
<hr><hr>
<table width ="100%">
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttX Binary Loader</i></font></big></h1>
<p>Last Updated: August 22, 2014</p>
</td>
</tr>
</table>
<hr><hr>
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
<h1>Table of Contents</h1>
</td>
</tr>
</table>
<ul>
<a href="#introduction">1.0 Introduction</a><br>
<a href="#binfmtif">2.0 Binary Loader Interface</a>
<ul>
<a href="#binfmthdr">2.1 Binary Loader Header Files</a><br>
<a href="#binfmtdata">2.2 Binary Loader Data Structures</a><br>
<a href="#binfmtfuncif">2.3 Binary Loader Function Interfaces</a>
</ul>
<a href="#symtab">3.0 Symbol Tables</a>
<ul>
<a href="#symtabhdr">3.1 Symbol Table Header Files</a><br>
<a href="#symtabdata">3.2 Symbol Table Data Structures</a><br>
<a href="#symtabfuncif">3.3 Symbol Table Function Interfaces</a>
</ul>
<a href="#configuration">4.0 Configuration Variables</a>
</ul>
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
<h1>1.0 <a name="introduction">Introduction</a></h1>
</td>
</tr>
</table>
<p>
<b>Binary Loaders</b>.
The purpose of a <i>binary loader</i> is to load and execute modules in various <i>binary formats</i> that reside in a file system.
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
<a href="NuttXNxFlat.html">NXFLAT documentation</a>.
</ul>
<p>
<b>Executables and Libraries</b>
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.
However, at this point in time, none of the supported binary formats support exporting of symbols.
</p>
<p>
<b>binfmt</b>.
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.
</p>
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
<h1>2.0 <a name="binfmtif">Binary Loader Interface</a></h1>
</td>
</tr>
</table>
<h2>2.1 <a name="binfmthdr">Binary Loader Header Files</a></h2>
<p>
The interface to the binary loader is described in the header file
<a href="http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/include/nuttx/binfmt/binfmt.h">
<code>include/nuttx/binfmt/binfmt.h</code></a>.
A brief summary of the data structurs and interfaces prototyped in that header file are listed below.
</p>
<h2>2.2 <a name="binfmtdata">Binary Loader Data Structures</a></h2>
<p>
When a binary format registers with the binary loader, it provides a pointer to a write-able instance of the following data structure:
</p>
<ul><pre>
struct binfmt_s
{
FAR struct binfmt_s *next; /* Supports a singly-linked list */
int (*load)(FAR struct binary_s *bin); /* Verify and load binary into memory */
};
</pre></ul>
<p>
The <code>load</code> method is used to load the binary format into memory.
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.
</p>
<p>
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 */
FAR const char *filename; /* Full path to the binary to be loaded */
FAR const char **argv; /* Argument list */
FAR const struct symtab_s *exports; /* Table of exported symbols */
int nexports; /* The number of symbols in exports[] */
/* Information provided from the loader (if successful) describing the
* resources used by the loaded module.
*/
main_t entrypt; /* Entry point into a program module */
FAR void *mapped; /* Memory-mapped, address space */
FAR void *alloc[BINFMT_NALLOC]; /* Allocated address spaces */
/* Constructors/destructors */
#ifdef CONFIG_BINFMT_CONSTRUCTORS
FAR binfmt_ctor_t *ctors; /* Pointer to a list of constructors */
FAR binfmt_dtor_t *dtors; /* Pointer to a list of destructors */
uint16_t nctors; /* Number of constructors in the list */
uint16_t ndtors; /* Number of destructors in the list */
#endif
/* Address environment.
*
* addrenv - This is the handle created by up_addrenv_create() that can be
* used to manage the tasks address space.
*/
#ifdef CONFIG_ARCH_ADDRENV
group_addrenv_t addrenv; /* Task group address environment */
#endif
size_t mapsize; /* Size of the mapped address region (needed for munmap) */
/* Start-up information that is provided by the loader, but may be modified
* by the caller between load_module() and exec_module() calls.
*/
uint8_t priority; /* Task execution priority */
size_t stacksize; /* Size of the stack in bytes (unallocated) */
};
</pre></ul>
<ul>
<p><small>
<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 <a href="#load_module"><code>load_module()</code></a> will attempt to load each file that is found at those absolute paths.
</small></p>
</ul>
<p>
Where the types <code>binfmt_ctor_t</code> and <code>binfmt_dtor_t</code> define the type of one C++ constructor or destructor:
</p>
<ul><pre>
typedef FAR void (*binfmt_ctor_t)(void);
typedef FAR void (*binfmt_dtor_t)(void);
</pre></ul>
<h2>2.3 <a name="binfmtfuncif">Binary Loader Function Interfaces</a></h2>
<h3>
Binary format management:
</h3>
<ul>
<a href="#register_binfmt">2.3.1 <code>register_binfmt()</code></a><br>
<a href="#unregister_binfmt">2.3.2 <code>unregister_binfmt()</code></a>
</ul>
<h3>
Basic module management:
</h3>
<ul>
<a href="#load_module">2.3.3 <code>load_module()</code></a><br>
<a href="#unload_module">2.3.4 <code>unload_module()</code></a><br>
<a href="#exec_module">2.3.5 <code>exec_module()</code></a><br>
<a href="#exec">2.3.6 <code>exec()</code></a><br>
<a href="#exec">2.3.7 <code>exec()</code></a>
</ul>
<h3>
<code>PATH</code> traversal logic:
</h3>
<ul>
<a href="#exepath_init">2.3.8 <code>exepath_init()</code></a><br>
<a href="#exepath_next">2.3.9 <code>exepath_next()</code></a><br>
<a href="#exepath_release">2.3.10 <code>exepath_release()</code></a>
</ul>
<h3>2.3.1 <a name="register_binfmt"><code>register_binfmt()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
int register_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.
</ul>
<h3>2.3.2 <a name="unregister_binfmt"><code>unregister_binfmt()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
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.
</ul>
<h3>2.3.3 <a name="load_module"><code>load_module()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
int load_module(FAR struct binary_s *bin);
</pre></ul>
<p><b>Description:</b></p>
<ul>
<p>
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 <a href="#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.
</p>
</ul>
<p><b>Returned Value:</b></p>
<ul>
This is an end-user function, so it follows the normal convention:
Returns 0 (<code>OK</code>) on success.
On failure, it returns -1 (<code>ERROR</code>) with <code>errno</code> set appropriately.
</ul>
<h3>2.3.4 <a name="unload_module"><code>unload_module()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
int unload_module(FAR struct binary_s *bin);
</pre></ul>
<p><b>Description:</b></p>
<ul>
<p>
Unload a (non-executing) module from memory.
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.
</ul>
<h3>2.3.5 <a name="exec_module"><code>exec_module()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
int exec_module(FAR const struct binary_s *bin);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Execute a module that has been loaded into memory by <code>load_module()</code>.
</ul>
<p><b>Returned Value:</b></p>
<ul>
This is an end-user function, so it follows the normal convention:
Returns 0 (<code>OK</code>) on success.
On failure, it returns -1 (<code>ERROR</code>) with <code>errno</code> set appropriately.
</ul>
<h3>2.3.7 <a name="exec"><code>exec()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
int exec(FAR const char *filename, FAR const char **argv,
FAR const struct symtab_s *exports, int nexports);
</pre></ul>
<p><b>Description:</b></p>
<ul>
This is a convenience function that wraps <code>load_</code> and <code>exec_module()</code> into one call.
</ul>
<p><b>Input Parameters:</b></p>
<ul>
<li><code>filename</code>: Full path to the binary to be loaded.</li>
<li><code>argv</code>: Argument list.</li>
<li><code>exports</code>: Table of exported symbols.</li>
<li><code>exports</code>: The number of symbols in exports.</li>
</ul>
<p><b>Returned Value:</b></p>
<ul>
This is an end-user function, so it follows the normal convention:
Returns 0 (<code>OK</code>) on success.
On failure, it returns -1 (<code>ERROR</code>) with <code>errno</code> set appropriately.
</ul>
<h3>2.3.8 <a name="exepath_init"><code>exepath_init()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
#ifdef CONFIG_BINFMT_EXEPATH
EXEPATH_HANDLE exepath_init(void);
#endif
</pre></ul>
<p><b>Description:</b></p>
<ul>
<p>
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.
</ul>
<h3>2.3.9 <a name="exepath_next"><code>exepath_next()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
#ifdef CONFIG_BINFMT_EXEPATH
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.
This memory must be freed by the called by calling <code>kmm_free()</code>.
</p>
<p>
<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>.
</p>
</ul>
<h3>2.3.10- <a name="exepath_release"><code>exepath_release()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/binfmt.h>
#ifdef CONFIG_BINFMT_EXEPATH
void exepath_release(EXEPATH_HANDLE handle);
#endif
</pre></ul>
<p><b>Description:</b></p>
<ul>
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>
</ul>
<p><b>Returned Value:</b> <i>None</i></p>
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
<h1>3.0 <a name="symtab">Symbol Tables</a></h1>
</td>
</tr>
</table>
<p>
<b>Symbol Tables</b>.
Symbol tables are lists of name value mappings:
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.
</p>
<h2>3.1 <a name="symtabhdr">Symbol Table Header Files</a></h2>
<p>
The interface to the symbol table logic is described in the header file
<a href="http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/include/nuttx/binfmt/symtab.h">
<code>include/nuttx/binfmt/symtab.h</code></a>.
A brief summary of the data structurs and interfaces prototyped in that header file are listed below.
</p>
<h2>3.2 <a name="symtabdata">Symbol Table Data Structures</a></h2>
<p>
<code>struct symbtab_s</code> describes one entry in the symbol table.
</p>
<ul><pre>
struct symtab_s
{
FAR const char *sym_name; /* A pointer to the symbol name string */
FAR const void *sym_value; /* The value associated witht the string */
};
</pre></ul>
</p>
A symbol table is a fixed size array of <code>struct symtab_s</code>.
The information is intentionally minimal and supports only:
</p>
<ol>
<li>
Function pointers as <code>sym_values</code>.
Of other kinds of values need to be supported, then typing information would also need to be included in the structure.
</li>
<li>
Fixed size arrays.
There is no explicit provisional for dyanamically adding or removing entries from the symbol table (realloc might be used for that purpose if needed).
The intention is to support only fixed size arrays completely defined at compilation or link time.
</li>
</ol>
<h2>3.3 <a name="symtabfuncif">Symbol Table Function Interfaces</a></h2>
<ul>
<a href="#symtab_findbyname">3.3.1 <code>symtab_findbyname()</code></a><br>
<a href="#symtab_findorderedbyname">3.3.2 <code>symtab_findorderedbyname()</code></a><br>
<a href="#symtab_findbyvalue">3.3.3 <code>symtab_findbyvalue()</code></a><br>
<a href="#symtab_findorderedbyvalue">3.3.4 <code>symtab_findorderedbyvalue()</code></a>
</ul>
<h3>3.3.1 <a name="symtab_findbyname"><code>symtab_findbyname()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/symtab.h>
FAR const struct symtab_s *
symtab_findbyname(FAR const struct symtab_s *symtab,
FAR const char *name, int nsyms);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Find the symbol in the symbol table with the matching name.
This version assumes that table is not ordered with respect to symbol name and, hence, access time will be linear with respect to <code>nsyms</code>.
</ul>
<p><b>Returned Value:</b></p>
<ul>
A reference to the symbol table entry if an entry with the matching name is found;
<code>NULL</code> is returned if the entry is not found.
</ul>
<h3>3.3.2 <a name="symtab_findorderedbyname"><code>symtab_findorderedbyname()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/symtab.h>
FAR const struct symtab_s *
symtab_findorderedbyname(FAR const struct symtab_s *symtab,
FAR const char *name, int nsyms);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Find the symbol in the symbol table with the matching name.
This version assumes that table ordered with respect to symbol name.
</ul>
<p><b>Returned Value:</b></p>
<ul>
A reference to the symbol table entry if an entry with the matching name is found;
<code>NULL</code> is returned if the entry is not found.
</ul>
<h3>3.3.3 <a name="symtab_findbyvalue"><code>symtab_findbyvalue()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/symtab.h>
FAR const struct symtab_s *
symtab_findbyvalue(FAR const struct symtab_s *symtab,
FAR void *value, int nsyms);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Find the symbol in the symbol table whose value closest (but not greater than), the provided value.
This version assumes that table is not ordered with respect to symbol name and, hence, access time will be linear with respect to <code>nsyms</code>.
</ul>
<p><b>Returned Value:</b></p>
<ul>
A reference to the symbol table entry if an entry with the matching name is found;
<code>NULL</code> is returned if the entry is not found.
</ul>
<h3>3.3.4 <a name="symtab_findorderedbyvalue"><code>symtab_findorderedbyvalue()</code></a></h3>
<p><b>Function Prototype:</b></p>
<ul><pre>
#include <:nuttx/binfmt/symtab.h>
FAR const struct symtab_s *
symtab_findorderedbyvalue(FAR const struct symtab_s *symtab,
FAR void *value, int nsyms);
</pre></ul>
<p><b>Description:</b></p>
<ul>
Find the symbol in the symbol table whose value closest (but not greater than), the provided value.
This version assumes that table is ordered with respect to symbol name.
</ul>
<p><b>Returned Value:</b></p>
<ul>
A reference to the symbol table entry if an entry with the matching name is found;
<code>NULL</code> is returned if the entry is not found.
</ul>
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
<h1>4.0 <a name="configuration">Configuration Variables</a></h1>
</td>
</tr>
</table>
<ul>
<p>
<code>CONFIG_BINFMT_DISABLE</code>:
By default, support for loadable binary formats is built.
This logic may be suppressed be defining this setting.
</p>
<p>
<code>CONFIG_BINFMT_CONSTRUCTORS</code>:
Build in support for C++ constructors in loaded modules.
</p>
<p>
<code>CONFIG_SYMTAB_ORDEREDBYNAME</code>:
Symbol tables are order by name (rather than value).
</p>
</ul>
<p>
Additional configuration options may be required for the each enabled binary format.
</p>
</body>
</html>
|
