1# Dynamic Loading 2 3## Basic Concepts 4 5In small devices with limited hardware resources, dynamic algorithm deployment capability is required to solve the problem that multiple algorithms cannot be deployed at the same time. The LiteOS-M kernel uses the Executable and Linkable Format \(ELF\) loading because it is easy to use and compatible with a wide variety of platforms. The LiteOS-M provides APIs similar to **dlopen** and **dlsym**. Apps can load and unload required algorithm libraries by using the APIs provided by the dynamic loading module. As shown in the following figure, the app obtains the corresponding information output through the API required by the third-party algorithm library. The third-party algorithm library depends on the basic APIs provided by the kernel, such as **malloc**. After the app loads the API and relocates undefined symbols, it can call the API to complete the function. The dynamic loading component supports only the Arm architecture. In addition, the signature and source of the shared library to be loaded must be verified to ensure system security. 6 7**Figure 1** LiteOS-M kernel dynamic loading architecture 8 9 10## Working Principles 11 12### Exporting the Symbol Table 13 14The kernel needs to proactively expose the API required by the dynamic library when the shared library calls a kernel API, as shown in the following figure. This mechanism compiles the symbol information to the specified section and calls the **SYM\_EXPORT** macro to export information of the specified symbol. The symbol information is described in the structure **SymInfo**. Its members include the symbol name and symbol address information. The macro **SYM\_EXPORT** imports the symbol information to the **.sym.\*** section by using the **\_\_attribute\_\_** compilation attribute. 15 16``` 17typedef struct { 18 CHAR *name; 19 UINTPTR addr; 20} SymInfo; 21 22#define SYM_EXPORT(func) \ 23const SymInfo sym_##func __attribute__((section(".sym."#func))) = { \ 24 .name = #func, \ 25 .addr = (UINTPTR)func \ 26}; 27``` 28 29**Figure 2** Exported symbol table information 30 31 32### Loading an ELF File 33 34During the loading process, the LOAD section to be loaded to the memory is obtained based on the ELF file handle and the section offset of the program header table. Generally, there are two sections: read-only section and read-write section. You can run the **readelf -l** command to view the LOAD section information of the ELF file. The physical memory is requested according to the related alignment attributes. Then, a code section or a data segment is written into the memory based on the loading base address and an offset of each section. 35 36``` 37$ readelf -l lib.so 38 39Elf file type is DYN (Shared object file) 40Entry point 0x5b4 41There are 4 program headers, starting at offset 52 42 43Program Headers: 44 Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 45 EXIDX 0x000760 0x00000760 0x00000760 0x00008 0x00008 R 0x4 46 LOAD 0x000000 0x00000000 0x00000000 0x0076c 0x0076c R E 0x10000 47 LOAD 0x00076c 0x0001076c 0x0001076c 0x0010c 0x00128 RW 0x10000 48 DYNAMIC 0x000774 0x00010774 0x00010774 0x000c8 0x000c8 RW 0x4 49 50 Section to Segment mapping: 51 Segment Sections... 52 00 .ARM.exidx 53 01 .hash .dynsym .dynstr .rel.dyn .rel.plt .init .plt .text .fini .ARM.exidx .eh_frame 54 02 .init_array .fini_array .dynamic .got .data .bss 55 03 .dynamic 56``` 57 58**Figure 3** Process of loading an ELF file 59 60 61### ELF File Link 62 63A relocation table is obtained by using a **.dynamic** section of the ELF file. Each entry that needs to be relocated in the table is traversed. Then, the symbol is searched, based on the symbol name that needs to be relocated, in the shared library and the exported symbol table provided by the kernel. The relocation information is updated based on the symbol found. 64 65**Figure 4** ELF file linking process 66 67 68## ELF Specifications 69 70### ELF Type 71 72When compiling a shared library, you can add **-fPIC** \(a compilation option\) to compile location-independent code. The shared library file type is **ET\_DYN**, which can be loaded to any valid address range. 73 74Example: **arm-none-eabi-gcc -fPIC –shared –o lib.so lib.c** 75 76### Options for Linking 77 781. **-nostdlib**: Do not use the lib library in the compiler when linking. 792. **-nostartfiles**: Do not use the startup files in the compiler when linking. 803. **-fPIC**: compiles location-independent shared libraries. 814. **-z max-page-size=4**: sets the number of alignment bytes of the loadable sections in the binary file to **4**. This setting saves memory and can be used for a dynamic library. 825. **-mcpu=** specifies the CPU architecture. 83 84
