基于OTAWA的tasking-Framework WCET分析：间接跳转问题求助

针对你在用OTAWA对tasking-Framework做WCET分析时遇到的标准库间接跳转无法解析的问题，我整理了两个方向的可行方案：

一、不引入标准库生成带正确CFG的有效ELF文件 #

如果不想依赖系统标准库，你可以通过手动实现必要的库函数存根（stub）来避免链接错误，同时保证控制流图的完整性：

• 手动实现极简标准库函数：针对报错的未定义引用（比如fvrwrit、signal、vfprintf相关函数），编写只满足你的应用需求的极简版本。比如把vfprintf简化为直接调用底层串口输出函数，跳过可变参数的复杂处理（如果你的应用不需要全功能格式化输出的话）；signal函数可以直接返回空或者一个固定值，只要能通过链接即可。
• 调整编译链接选项：使用编译器的--nostdlib或-nodefaultlibs参数禁用默认标准库，同时将你自己实现的存根文件加入编译。例如（以ARM GCC为例）：

  arm-none-eabi-gcc -mcpu=cortex-m4 --nostdlib your_app.c your_std_stubs.c startup.s -T linker.ld -o output.elf
  

• 确保启动与链接配置正确：需要提供自定义的启动文件（startup.s）和链接脚本（linker.ld），负责初始化栈、设置入口点（main或Reset_Handler），避免依赖标准库的初始化流程。

二、强制编译器生成直接分支而非间接跳转 #

如果必须保留标准库，可以通过编译器和链接器选项来抑制间接分支的生成：

• 调整优化级别：高优化级别（如-O2、-O3）容易触发跳转表或间接跳转生成，尝试降低到-O0或-O1测试，不过这会增大代码体积，可能影响WCET分析的参考性，需权衡。
• 禁用跳转表与间接分支：对于GCC，使用-fno-jump-tables禁止生成基于跳转表的间接分支，或者-fno-indirect-branch更全面地禁用间接分支优化。例如：

  arm-none-eabi-gcc -mcpu=cortex-m4 -O1 -fno-jump-tables -specs=nonsys.specs your_app.c -o output.elf
  

• 定制标准库编译宏：如果使用Newlib这类可配置的标准库，尝试添加宏定义来避免间接分支。比如-D__NO_INDIRECT_BRANCHES（部分库支持该宏，强制生成直接分支），配合-specs=nano.specs使用轻量版库：

  arm-none-eabi-gcc -mcpu=cortex-m4 -O2 -D__NO_INDIRECT_BRANCHES -specs=nano.specs your_app.c -o output.elf
  

• 替换特定标准库函数：对于顽固的间接分支函数（比如vfprintf），可以用链接器的--wrap选项替换为自己实现的无间接分支版本。例如：

  arm-none-eabi-gcc -mcpu=cortex-m4 -specs=nonsys.specs -Wl,--wrap=vfprintf your_app.c your_vfprintf_stub.c -o output.elf
  

  然后在your_vfprintf_stub.c中实现__wrap_vfprintf函数，替代原标准库版本。

额外注意事项 #

• 无论采用哪种方案，都要验证生成的ELF文件：用objdump -d output.elf反汇编，检查是否还存在bx rX、ldr pc, [pc, #offset]这类间接跳转指令；同时用OTAWA加载ELF，确认控制流图解析正常。
• 如果你的应用依赖标准库的复杂功能，手动实现存根可能成本较高，优先尝试编译器选项调整的方案。

内容的提问来源于stack exchange，提问作者Hazem Abaza