dlfcn.h 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317
  1. /****************************************************************************
  2. * include/dlfcn.h
  3. *
  4. * Licensed to the Apache Software Foundation (ASF) under one or more
  5. * contributor license agreements. See the NOTICE file distributed with
  6. * this work for additional information regarding copyright ownership. The
  7. * ASF licenses this file to you under the Apache License, Version 2.0 (the
  8. * "License"); you may not use this file except in compliance with the
  9. * License. You may obtain a copy of the License at
  10. *
  11. * http://www.apache.org/licenses/LICENSE-2.0
  12. *
  13. * Unless required by applicable law or agreed to in writing, software
  14. * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  15. * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
  16. * License for the specific language governing permissions and limitations
  17. * under the License.
  18. *
  19. ****************************************************************************/
  20. #ifndef __INCLUDE_DLFCN_H
  21. #define __INCLUDE_DLFCN_H
  22. /****************************************************************************
  23. * Included Files
  24. ****************************************************************************/
  25. #include <nuttx/config.h>
  26. #include <sys/types.h>
  27. /****************************************************************************
  28. * Pre-processor Definitions
  29. ****************************************************************************/
  30. /* The dlfcn.h header defines at least the following macros for use in the
  31. * construction of a dlopen() mode argument:
  32. *
  33. * RTLD_LAZY - Relocations are performed at an implementation-dependent
  34. * time, ranging from the time of the dlopen() call until
  35. * the first reference to a given symbol occurs. Specifying
  36. * RTLD_LAZY should improve performance on implementations
  37. * supporting dynamic symbol binding as a process may not
  38. * reference all of the functions in any given object. And,
  39. * for systems supporting dynamic symbol resolution for
  40. * normal process execution, this behaviour mimics the
  41. * normal handling of process execution.
  42. * RTLD_NOW - All necessary relocations are performed when the object
  43. * is first loaded. This may waste some processing if
  44. * relocations are performed for functions that are never
  45. * referenced. This behaviour may be useful for
  46. * applications that need to know as soon as an object is
  47. * loaded that all symbols referenced during execution will
  48. * be available.
  49. *
  50. * Any object loaded by dlopen() that requires relocations against global
  51. * symbols can reference the symbols in the original process image file,
  52. * any objects loaded at program startup, from the object itself as well as
  53. * any other object included in the same dlopen() invocation, and any
  54. * objects that were loaded in any dlopen() invocation and which specified
  55. * the RTLD_GLOBAL flag. To determine the scope of visibility for the
  56. * symbols loaded with a dlopen() invocation, the mode parameter should be
  57. * bitwise or'ed with one of the following values:
  58. *
  59. * RTLD_GLOBAL - The object's symbols are made available for the
  60. * relocation processing of any other object. In addition,
  61. * symbol lookup using dlopen(0, mode) and an associated
  62. * dlsym() allows objects loaded with this mode to be
  63. * searched.
  64. * RTLD_LOCAL - All symbols are not made available for relocation
  65. * processing by other modules.
  66. *
  67. * Reference: OpenGroup.org
  68. */
  69. #define RTLD_LAZY (0 << 0)
  70. #define RTLD_NOW (1 << 0)
  71. #define RTLD_GLOBAL (1 << 1)
  72. #define RTLD_LOCAL (1 << 2)
  73. /****************************************************************************
  74. * Public Function Prototypes
  75. ****************************************************************************/
  76. #ifdef __cplusplus
  77. #define EXTERN extern "C"
  78. extern "C"
  79. {
  80. #else
  81. #define EXTERN extern
  82. #endif
  83. /****************************************************************************
  84. * Name: dlsymtab
  85. *
  86. * Description:
  87. * dlsymtab() is a non-standard shared library interface. It selects the
  88. * symbol table to use when binding a shared library to the base firmware
  89. * which may be in FLASH memory.
  90. *
  91. * Input Parameters:
  92. * symtab - The new symbol table.
  93. * nsymbols - The number of symbols in the symbol table.
  94. *
  95. * Returned Value:
  96. * Always returns OK.
  97. *
  98. ****************************************************************************/
  99. struct symtab_s;
  100. int dlsymtab(FAR const struct symtab_s *symtab, int nsymbols);
  101. /****************************************************************************
  102. * Name: dlopen
  103. *
  104. * Description:
  105. * dlopen() makes an executable object file specified by file available to
  106. * the calling program. The class of files eligible for this operation and
  107. * the manner of their construction are specified by the implementation,
  108. * though typically such files are executable objects such as shared
  109. * libraries, relocatable files or programs. Note that some implementations
  110. * permit the construction of dependencies between such objects that are
  111. * embedded within files. In such cases, a dlopen() operation will load
  112. * such dependencies in addition to the object referenced by file.
  113. * Implementations may also impose specific constraints on the construction
  114. * of programs that can employ dlopen() and its related services.
  115. *
  116. * If a file is specified in multiple dlopen() invocations, mode is
  117. * interpreted at each invocation. Note, however, that once RTLD_NOW has
  118. * been specified all relocations will have been completed rendering
  119. * further RTLD_NOW operations redundant and any further RTLD_LAZY
  120. * operations irrelevant. Similarly note that once RTLD_GLOBAL has been
  121. * specified the object will maintain the RTLD_GLOBAL status regardless
  122. * of any previous or future specification of RTLD_LOCAL, so long as the
  123. * object remains in the address space (see dlclose()).
  124. *
  125. * Symbols introduced into a program through calls to dlopen() may be
  126. * used in relocation activities. Symbols so introduced may duplicate
  127. * symbols already defined by the program or previous dlopen()
  128. * operations. To resolve the ambiguities such a situation might
  129. * present, the resolution of a symbol reference to symbol definition is
  130. * based on a symbol resolution order. Two such resolution orders are
  131. * defined: load or dependency ordering. Load order establishes an
  132. * ordering among symbol definitions, such that the definition first
  133. * loaded (including definitions from the image file and any dependent
  134. * objects loaded with it) has priority over objects added later (via
  135. * dlopen()). Load ordering is used in relocation processing. Dependency
  136. * ordering uses a breadth-first order starting with a given object,
  137. * then all of its dependencies, then any dependents of those, iterating
  138. * until all dependencies are satisfied. With the exception of the global
  139. * symbol object obtained via a dlopen() operation on a file of 0,
  140. * dependency ordering is used by the dlsym() function. Load ordering is
  141. * used in dlsym() operations upon the global symbol object.
  142. *
  143. * When an object is first made accessible via dlopen() it and its
  144. * dependent objects are added in dependency order. Once all the objects
  145. * are added, relocations are performed using load order. Note that if an
  146. * object or its dependencies had been previously loaded, the load and
  147. * dependency orders may yield different resolutions.
  148. *
  149. * The symbols introduced by dlopen() operations, and available through
  150. * dlsym() are at a minimum those which are exported as symbols of global
  151. * scope by the object. Typically such symbols will be those that were
  152. * specified in (for example) C source code as having extern linkage. The
  153. * precise manner in which an implementation constructs the set of
  154. * exported symbols for a dlopen() object is specified by that
  155. * implementation.
  156. *
  157. * Input Parameters:
  158. * file - Used to construct a pathname to the object file. If file
  159. * contains a slash character, the file argument is used as the
  160. * pathname for the file. Otherwise, file is used in an
  161. * implementation-dependent manner to yield a pathname.
  162. *
  163. * If the value of file is 0, dlopen() provides a handle on a
  164. * global symbol object. This object provides access to the symbols
  165. * from an ordered set of objects consisting of the original
  166. * program image file, together with any objects loaded at program
  167. * startup as specified by that process image file (for example,
  168. * shared libraries), and the set of objects loaded using a
  169. * dlopen() operation together with the RTLD_GLOBAL flag. As the
  170. * latter set of objects can change during execution, the set
  171. * identified by handle can also change dynamically.
  172. *
  173. * Only a single copy of an object file is brought into the address
  174. * space, even if dlopen() is invoked multiple times in reference
  175. * to the file, and even if different pathnames are used to
  176. * reference the file.
  177. * mode - Describes how dlopen() will operate upon file with respect to
  178. * the processing of relocations and the scope of visibility of the
  179. * symbols provided within file. When an object is brought into the
  180. * address space of a process, it may contain references to symbols
  181. * whose addresses are not known until the object is loaded. These
  182. * references must be relocated before the symbols can be accessed.
  183. * The mode parameter governs when these relocations take place.
  184. * See definitions above for values of the mode parameter:.
  185. *
  186. * Returned Value:
  187. * A successful dlopen() returns a handle which the caller may use on
  188. * subsequent calls to dlsym() and dlclose(). The value of this handle
  189. * should not be interpreted in any way by the caller.
  190. *
  191. * If file cannot be found, cannot be opened for reading, is not of an
  192. * appropriate object format for processing by dlopen(), or if an error
  193. * occurs during the process of loading file or relocating its symbolic
  194. * references, dlopen() will return NULL. More detailed diagnostic
  195. * information will be available through dlerror().
  196. *
  197. * Reference: OpenGroup.org
  198. *
  199. * **************************************************************************/
  200. FAR void *dlopen(FAR const char *file, int mode);
  201. /****************************************************************************
  202. * Name: dlsym
  203. *
  204. * Description:
  205. * dlsym() allows a process to obtain the address of a symbol defined
  206. * within an object made accessible through a dlopen() call. handle is the
  207. * value returned from a call to dlopen() (and which has not since been
  208. * released via a call to dlclose()), name is the symbol's name as a
  209. * character string.
  210. *
  211. * dlsym() will search for the named symbol in all objects loaded
  212. * automatically as a result of loading the object referenced by handle
  213. * (see dlopen()). Load ordering is used in dlsym() operations upon the
  214. * global symbol object. The symbol resolution algorithm used will be
  215. * dependency order as described in dlopen().
  216. *
  217. * Input Parameters:
  218. * handle - The opaque, non-NULL value returned by a previous successful
  219. * call to dlopen().
  220. * name - A pointer to the symbol name string.
  221. *
  222. * Returned Value:
  223. * If handle does not refer to a valid object opened by dlopen(), or if
  224. * the named symbol cannot be found within any of the objects associated
  225. * with handle, dlsym() will return NULL. More detailed diagnostic
  226. * information will be available through dlerror().
  227. *
  228. * Reference: OpenGroup.org
  229. *
  230. ****************************************************************************/
  231. FAR void *dlsym(FAR void *handle, FAR const char *name);
  232. /****************************************************************************
  233. * Name: dlclose
  234. *
  235. * Description:
  236. * dlclose() is used to inform the system that the object referenced by a
  237. * handle returned from a previous dlopen() invocation is no longer needed
  238. * by the application.
  239. *
  240. * The use of dlclose() reflects a statement of intent on the part of the
  241. * process, but does not create any requirement upon the implementation,
  242. * such as removal of the code or symbols referenced by handle. Once an
  243. * object has been closed using dlclose() an application should assume
  244. * that its symbols are no longer available to dlsym(). All objects loaded
  245. * automatically as a result of invoking dlopen() on the referenced object
  246. * are also closed.
  247. *
  248. * Although a dlclose() operation is not required to remove structures
  249. * from an address space, neither is an implementation prohibited from
  250. * doing so. The only restriction on such a removal is that no object will
  251. * be removed to which references have been relocated, until or unless all
  252. * such references are removed. For instance, an object that had been
  253. * loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might
  254. * provide a target for dynamic relocations performed in the processing of
  255. * other objects - in such environments, an application may assume that no
  256. * relocation, once made, will be undone or remade unless the object
  257. * requiring the relocation has itself been removed.
  258. *
  259. * Input Parameters:
  260. * handle - The opaque, non-NULL value returned by a previous successful
  261. * call to dlopen().
  262. *
  263. * Returned Value:
  264. * If the referenced object was successfully closed, dlclose() returns 0.
  265. * If the object could not be closed, or if handle does not refer to an
  266. * open object, dlclose() returns a non-zero value. More detailed
  267. * diagnostic information will be available through dlerror().
  268. *
  269. * Reference: OpenGroup.org
  270. * *************************************************************************/
  271. int dlclose(FAR void *handle);
  272. /****************************************************************************
  273. * Name: dlerror
  274. *
  275. * Description:
  276. * dlerror() returns a null-terminated character string (with no trailing
  277. * newline) that describes the last error that occurred during dynamic
  278. * linking processing. If no dynamic linking errors have occurred since
  279. * the last invocation of dlerror(), dlerror() returns NULL. Thus,
  280. * invoking dlerror() a second time, immediately following a prior
  281. * invocation, will result in NULL being returned.
  282. *
  283. * Input Parameters:
  284. * If successful, dlerror() returns a null-terminated character string.
  285. * Otherwise, NULL is returned.
  286. *
  287. * Returned Value:
  288. *
  289. * Reference: OpenGroup.org
  290. *
  291. ****************************************************************************/
  292. FAR char *dlerror(void);
  293. #undef EXTERN
  294. #ifdef __cplusplus
  295. }
  296. #endif
  297. #endif /* __INCLUDE_DLFCN_H */