Target Shell 符号表加载方法

 Todule Unloader

To make full use of the target shell's features, you should also define the target symbol table, as well as the target module loader and unloader. Select the following components (identified by their associated macros) in the VxWorks view (see Tornado User's Guide: Projects for configuration information):

  • INCLUDE_SYM_TBL for target symbol table support, plus one of the following:

  • INCLUDE_NET_SYM_TBL to load the symbol table from the network (vxWorks.sym; you will also need to separately load vxWorks)

  • INCLUDE_STANDALONE_SYM_TBL to build a VxWorks image that includes the target symbol table (vxWorks.st)

  • INCLUDE_LOADER

  • INCLUDE_UNLOADER

If the target symbol table is included, usrRoot( ) runs hashLibInit( ) and symLibInit( )to initialize the corresponding libraries. The target symbol table is created by calling symTblCreate( ). For convenience during debugging (see 9.2.3 Debugging with the Target Shell), it is most useful to have access to all symbols in the system. On the other hand, a production version of a system can be built that does not require the target symbol table, if (for example) memory resources are constrained.

The symTblCreate( ) call creates an empty target symbol table. VxWorks system facilities are not accessible through the target shell until the symbol definitions for the booted VxWorks system are entered into the target symbol table. This is done by reading the target symbol table from a file called vxWorks.sym in the same directory from which vxWorks was loaded (installDir/target/config/bspname). This file contains an object module that consists only of a target symbol table section containing the symbol definitions for all the variables and routines in the booted system module. It has zero-length (empty) code, data, and relocation sections. Nonetheless, it is a legitimate object module in the standard object module format.

The symbols in vxWorks.sym are entered in the target symbol table by calling loadSymTbl( ) (whose source is in installDir/target/src/config/usrLoadSym.c). This routine uses the target-resident module loader to load symbols from vxWorks.sym into the target symbol table.

For the most part, the target-resident facilities work the same as their Tornado host counterparts; see 8.9.1 Creating a Standalone VxWorks System with a Built-in Symbol Table, 8.4.4 Downloading an Application Module, and 8.4.6 Unloading Modules. However, as stated earlier, the target-resident facilities can be useful if you are building dynamically configured applications. For example, with the target-resident loader, you can load from a target disk as well as over the network, with these caveats: If you use the target-resident loader to load a module over the network (as opposed to loading from a target-system disk), the amount of memory required to load an object module depends on what kind of access is available to the remote file system over the network. Loading a file that is mounted over the default network driver requires enough memory to hold two copies of the file simultaneously. First, the entire file is copied to a buffer in local memory when opened; second, the file resides in memory when it is linked to VxWorks. On the other hand, loading an object module from a host file system mounted through NFS only requires enough memory for one copy of the file (plus a small amount of overhead). In any case, however, using the target-resident loader takes away additional memory from your application--most significantly for the target-resident symbol table required by the target-resident loader.

For information on the target-resident module loader, unloader, and symbol table, see the loadLib, unldLib, and symLib reference entries.


### 关于 `pwd` 命令的用法 在 Shell 中,`pwd` 是 **Print Working Directory** 的缩写,用于显示当前工作目录的绝对路径。该命令不接受任何参数,执行后会返回当前所在的工作目录位置。 例如,在脚本中可以通过以下方式获取并打印当前目录的绝对路径[^1]: ```bash SHELL_FOLDER=$(cd "$(dirname "$0")"; pwd) echo $SHELL_FOLDER ``` 这里的关键点在于: - 使用 `$(dirname "$0")` 获取脚本所在的相对路径。 - 结合 `cd` 和 `pwd` 将其转换为绝对路径。 --- ### 静态库 `libevent.a` 调用中的路径问题分析 #### 问题描述 当尝试链接静态库 `libevent.a` 时,可能会遇到未定义符号错误(如 `arc4random_addrandom`),这通常是因为缺少必要的依赖项或者链接器无法找到这些依赖项所致。 #### 可能的原因及解决方案 1. **缺失依赖库** 如果 `libevent.a` 内部调用了其他系统的标准库函数(如 `arc4random_addrandom`),而这些函数并未被正确链接到最终的目标文件中,则会出现此错误。可以尝试显式指定所需的系统库来解决问题[^3]。 修改 Makefile 或者编译选项,加入 `-lcrypto` 参数以引入 OpenSSL 库支持随机数生成功能: ```makefile LDFLAGS += -lcrypto ``` 2. **环境变量配置不当** 当前 shell 下可能未设置正确的库搜索路径 (`LD_LIBRARY_PATH`) 导致动态加载失败。虽然这里是针对静态库的情况,但如果某些工具链内部仍然涉及动态查找机制的话也可能受到影响[^1]。 设置合适的库路径如下所示: ```bash export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/path/to/your/libs/ ``` 3. **交叉编译场景下的平台匹配问题** 若是在不同架构之间进行交叉编译操作,则需特别关注所选编译器及其关联的标准C/C++运行时库版本是否一致。因为即使同名头文件也有可能因ABI差异而导致兼容性障碍[^3]。 确认使用的 NDK 版本号以及目标硬件平台信息无误之后再继续构建过程即可规避此类风险。 4. **链接顺序调整** 对于 GNU 工具集而言,放置对象文件(.o)与档案文件(.a)之间的次序非常重要。如果先指定了 `.a` 文件而后才给出它所需要的外部引用则可能导致解析不到相应实体从而报错。因此建议按照实际需求合理安排各项输入要素的位置关系[^5]。 --- ### 示例修正后的 Makefile 片段 以下是经过改进的一个简单例子供参考: ```makefile CC=gcc CFLAGS=-Wall -O2 LDFLAGS=-levent -lcrypto TARGET=example_program all: $(TARGET) $(TARGET): main.o utils.o $(CC) $^ -o $@ $(LDFLAGS) clean: rm -f *.o $(TARGET) ``` 其中加入了对加密算法的支持以便满足特定条件下对于安全性的额外诉求。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值