简介面向32位Modelsim与Questasim用户的GCC 4.2.1集成包针对仿真环境缺少匹配编译器、C/C源码难以在验证流程中直接编译链接的痛点适合硬件验证、FPGA/ASIC设计及嵌入式开发人员使用也兼顾VC9与MinGW32构建环境的兼容需求。压缩包共1204个文件、约22.81MB含592个C头文件、265个C头文件、173个静态库、17个可执行程序以及tcc、o、la等编译链接中间文件和配置脚本头文件提供标准库与接口声明静态库用于链接可执行程序承担编译工具角色整体覆盖工具链、库与配置三类内容。已有775人学习下载。读者可借此补齐仿真器的编译能力在Verilog/VHDL测试平台中编译C/C模型、验证处理器IP核并开展软硬件协同调试完整的头文件与库文件也有助于排查版本匹配、运行库差异、路径配置和链接错误减少自行拼装工具链的时间。1. 一份 30MB 的 gcc 4.2.1 压缩包为什么在 ModelSim 仿真里能救命仿真跑得好好的加了一段 DPI-C 就突然报找不到 gcc或者加载 DLL 时提示找不到指定模块——这类报错在 Windows 上出现时八成不是代码写错了而是 modelsim 安装目录里那份自带的外部编译器被清理工具截走了。modelsim-gcc-4.2.1-mingw32vc9.zip 就是这份工具链的独立副本32 位 MinGW 打包的 gcc 4.2.1对齐 vc9 那一代 C 运行时专门用来把 C/C 源码编成 Windows 动态库供 vsim 通过 DPI-C、PLI/VPI 或 SystemC 三条通路调用。它适合三类人仿真器版本偏老、安装目录里 gcc 已失效需要原样补回的要在没有完整仿真环境的机器上单独编 DPI 库的以及要复现旧工程编译参数的。它不是通用编译器版本停在 2007 年C11 及以后的东西基本没有——这个边界后面会反复提到。2. 拆包先看清构成mingw32、4.2.1、vc9 三个词各自卡住什么拿到压缩包别急着解压到工程目录先把命名里那三个词拆开看。它们不是随手的版本标记每一个都对应一条硬约束任何一条对不上编出来的库在 vsim 里就是加载失败或者跑出诡异结果。这一章做完你至少能回答三个问题这个工具链能编什么、编出来的东西能被谁加载、以及它和安装目录里那份是不是同一路货。2.1 MinGW32 与 vc9 后缀两条不能越过的边界先看 mingw32。它表示目标三元组是 i686-pc-mingw32产物是 32 位 PE 格式的 .dll 和 .exe运行期依赖系统自带的 msvcrt.dll。这条边界非常硬32 位的 vsim.exe 只能加载 32 位 DLL反过来 64 位版仿真器加载这份工具链编出来的库会直接失败。判断方法很简单看一眼安装目录下 win32 还是 win64或者任务管理器里进程后面有没有“(32 位)”。很多人是在 64 位仿真器上拿这份工具链去编编的时候一路绿灯加载的时候才炸中间没有任何提示。再看 vc9。这个后缀指的是工具链对齐 Visual C 9.0VS2008那一代 C 运行时的构建约定主要影响的是 CRT 版本假设、结构体打包规则和异常模型。MinGW 用的是 GCC 自己的异常实现MSVC 用的是 SEH两边的目标文件不能直接混链C 的名字修饰规则也完全不同。所以如果你的工程里混着别的编译器产出的 .obj 或 .lib链接阶段会冒出一堆无法解析的符号看着像是少库实际是 ABI 不兼容。我的建议很明确这条通路上只写 C只通过 C 接口和仿真器交互。函数参数用 int、double、指针、定长数组这类基本类型需要传结构体就显式按 4 字节对齐绝对不要在跨边界的地方出现 std::string、std::vector 或者任何带虚函数的类。C 可以写但把它关在 DLL 内部对外只暴露extern C的纯 C 签名。这条经验值很多次重装。最后是 4.2.1 这个版本号。GCC 4.2.1 发布于 2007 年C 语言这边 C99 支持得七七八八C 这边停在 C98auto、nullptr、范围 for、std::thread、变参模板统统没有。如果你手上是从别处拷来的 C 源码编译报一堆语法错误先别怀疑工具链坏了翻一翻源码里有没有 C11 的写法。旧版仿真器自带的 SystemC 库也是按这个年代的编译器编的环环相扣。2.2 ModelSim 什么时候会去外部找编译器三条通路各要什么搞清楚工具链的边界之后还要知道仿真器在哪些时刻会真的用到它。日常跑纯 Verilog/VHDL 是不碰 gcc 的一旦涉及下面三条通路gcc 就必须在位。第一条是 DPI-C也是最常见的一条。SystemVerilog 侧用import DPI-C声明一个外部函数C 侧提供实现编译成 DLL仿真时用vsim -sv_lib挂上去。这条通路的优点是简单不需要链接任何仿真器提供的库纯计算、纯查表的加速特别适合。第二条是 PLI/VPI老工程里非常多。C 侧#include vpi_user.h在vpi_register_systf之类的入口里注册系统任务编译成 DLL 后用vsim -pli加载。这条通路的符号是在加载时由 vsim 进程解析的所以不能静态链接仿真器的库头文件路径必须指向安装目录下的 include。第三条是 SystemC 协同仿真。sccom命令在底层调用 gcc 把 SystemC 源码编成对象文件再和 HDL 侧一起链接。这条路上工具链的版本敏感度最高因为 SystemC 库本身是用同一个编译器编出来的版本、异常模型、线程模型任何一项对不上链接或运行期就会出问题。三条通路的共同点是产物都是被塞进 vsim 进程里的二进制位数必须和宿主进程一致DPI 调用发生在仿真线程内C 侧函数不要阻塞、不要自己起线程去读写 SV 侧的数据结构否则会出现那种“跑一万次对一次、换个种子就错”的玄学问题。2.3 解压后的三分钟自检目录、版本、目标架构解压之前先想清楚放哪。我的习惯是放在一个纯英文、无空格的固定路径下比如D:\tools\modelsim-gcc-4.2.1不要放在桌面或者“我的文档”里中文路径在旧版 gcc 上翻车概率不低。下面这段 PowerShell 做三件事解压、列目录、跑版本自检。# 解压到固定路径路径不要带空格和中文 $dst D:\tools\modelsim-gcc-4.2.1 Expand-Archive -Path .\modelsim-gcc-4.2.1-mingw32vc9.zip -DestinationPath $dst -Force # 列出 bin 目录确认核心可执行文件齐全 Get-ChildItem $dst\bin | Select-Object Name, Length | Format-Table -AutoSize # 版本与目标三元组自检 $dst\bin\gcc.exe -dumpversion # 期望输出 4.2.1 $dst\bin\gcc.exe -dumpmachine # 期望 i686-pc-mingw32三行输出要分别看。-dumpversion打出 4.2.1说明版本对得上-dumpmachine打出 i686-pc-mingw32说明确实是 32 位目标。如果bin目录里缺gcc.exe、ld.exe、as.exe中的任何一个或者解压过程中被安全软件静默删掉了文件后面所有步骤都是白费。再补一步架构确认看产物本身是不是 32 位 PE# 用 objdump 看一个可执行文件的 PE 头确认是 PE32 而不是 PE32 objdump -f $dst/bin/gcc.exe | head -5输出里出现file format pei-i386就对了。如果显示pei-x86-64说明你拿到的不是这份 mingw32 包或者被替换过。这一步看着多余但我确实遇到过把 64 位工具链改个目录名当 32 位用的情形症状是编译一切正常、加载必失败排查方向会被带偏很久。3. 接进流程从 PATH 顺序到第一个能跑的 DPI-C 动态库工具链自检通过接下来是把它接进仿真流程。这一步的难点不在编译命令本身而在“让谁去调用它”。Windows 上同时装了多套 MinGW 是很常见的事PATH 里谁排在前面vsim或你的构建脚本就会命中谁命错了版本报错信息往往指向别处。这一章按“先定位、再跑通、后调参”的顺序推进跑完你应该有一个能在 vsim 里打印出结果的最小 DPI-C 例子。3.1 PATH、modelsim.ini 与调用顺序让 vsim 找得到这份 gcc最省事的做法是把bin目录塞进当前会话的 PATH 最前面。注意是“最前面”不是“追加上去”。Windows 上where gcc会按 PATH 顺序列出所有命中的可执行文件第一条就是实际生效的那一条。# 只在当前 PowerShell 会话生效避免污染系统环境变量 $env:PATH D:\tools\modelsim-gcc-4.2.1\bin; $env:PATH # 确认第一条命中的就是我们这份 where.exe gcc gcc -dumpversionwhere.exe gcc如果第一条不是你刚加进去的路径说明系统里还有别的 MinGW而且优先级更高。这种情况下不要靠改 PATH 硬碰直接在构建脚本里写绝对路径调用D:\tools\modelsim-gcc-4.2.1\bin\gcc.exe可控性高得多。我后来统一改成绝对路径调用PATH 只用来兜底省掉了很多“本机好好的、换台机器就编不过”的麻烦。有些版本的仿真器会在 modelsim.ini 里留出外部编译器的配置项改之前一定先备份整个 ini然后只改你确认语义的那一项。改错的后果是整份 ini 失效仿真器启动时回退到默认配置症状表现为一堆莫名其妙的库路径找不到。相比之下用会话级 PATH 或者构建脚本里的绝对路径影响面小、可回滚我更推荐这条路。还有一个容易被忽略的点vsim 加载 DLL 时DLL 自身依赖的运行库也要能被找到。MinGW 编出来的 DLL 默认动态依赖libgcc_s_dw2-1.dll若用了 C 还会依赖libstdc-6.dll。这两个文件就在工具链的bin里vsim 进程启动时如果 PATH 里没有这个目录就会报“找不到指定的模块”。解决办法有两条后面 4.2 节会展开一是把bin加进 PATH二是编译时静态链接让 DLL 不依赖外部运行库。后者更稳我一般直接用后者。3.2 一个最小 DPI-C 例子从 C 源码到 vsim 里打印出结果先写 C 侧。这个例子故意做得很小一个整数加法一个把数组求和的函数覆盖标量和数组两种常见传参形态。/* mydpi.c —— 对外只暴露 C 签名不引入任何 C 类型 */ #include stdio.h /* 标量传参最简单也最不容易出问题的一类 */ int dpi_add(int a, int b) { return a b; } /* 数组传参注意长度单独传不要指望在 C 侧推断 */ int dpi_sum(const int *data, int len) { int s 0; int i; for (i 0; i len; i) { s data[i]; } return s; } /* 带副作用的函数用来确认调用确实发生在仿真线程内 */ void dpi_log(int tag) { printf([DPI] tag %d\n, tag); fflush(stdout); /* 不刷新的话输出可能被缓冲到仿真结束才出现 */ }SystemVerilog 侧的声明必须和 C 侧签名严格对应参数方向、位宽、数组维度错一个编译不报错但结果是乱的。// tb_dpi.sv —— import 声明要和 C 侧签名逐字对应 module tb_dpi; import DPI-C function int dpi_add(input int a, input int b); import DPI-C function int dpi_sum(input int data[], input int len); import DPI-C function void dpi_log(input int tag); int arr[4] {1, 2, 3, 4}; int total; initial begin $display(add %0d, dpi_add(3, 4)); total dpi_sum(arr, 4); $display(sum %0d, total); dpi_log(42); $finish; end endmodule编译命令的关键在三个地方-shared生成 DLL、-I指向仿真器安装目录的 include、-Wl,--export-all-symbols保证符号被导出。# 注意换成你自己的仿真器安装路径路径用正斜杠或双反斜杠 gcc -shared -O2 -fno-strict-aliasing \ -IC:/modeltech/include \ -Wl,--export-all-symbols \ -static-libgcc \ -o mydpi.dll mydpi.c逐个解释。-shared让链接器产出 DLL 而不是 exe-O2是常用优化等级如果你的函数里有为了调试方便加的打印先降到-O0确认逻辑正确再升-fno-strict-aliasing针对跨语言传指针的场景关闭严格别名优化避免编译器做出违反直觉的重排-I后面那个目录里应该有svdpi.h、vpi_user.h、veriuser.h这些头文件路径不对会直接报找不到头文件-Wl,--export-all-symbols是 MinGW 下最省事的导出方式不用在 C 代码里到处写__declspec(dllexport)-static-libgcc把 GCC 运行库静态链进去DLL 就不再依赖libgcc_s_dw2-1.dll加载时少一个失败点。跑仿真时-sv_lib后面不要带 .dll 后缀这是很多人第一次就卡住的地方# run_dpi.tcl —— 用批处理模式跑方便放进 CI vlib work vlog -sv tb_dpi.sv vsim -c -sv_lib mydpi tb_dpi run -all quit -fvsim -c是命令行模式不弹图形界面输出直接打到终端里适合脚本化。-sv_lib mydpi告诉仿真器去加载mydpi.dll搜索路径默认是当前目录库在别的目录时用-sv_root指定。跑通的话终端里会出现add 7、sum 10和[DPI] tag 42三行。3.3 PLI/VPI 与 SystemC链接参数差在哪三条通路的编译命令骨架是一样的差别集中在头文件、链接库和符号导出三块。下面这张表是我自己反复对照用的放在手边能省掉很多试错。通路必需头文件典型编译参数加载方式常见失败点DPI-Csvdpi.h可选-shared -Wl,--export-all-symbolsvsim -sv_lib xxx忘了-static-libgcc加载时报缺模块PLI/VPIvpi_user.h、veriuser.h-shared -Iinstall/includevsim -pli xxx.dll静态链接了仿真器库符号冲突SystemCSystemC 与sccom相关头文件由sccom生成-I指向 SC 库随设计一起链接工具链版本与 SC 库不匹配PLI/VPI 那条要特别注意不要去静态链接仿真器提供的任何 .a 或 .lib。VPI 的符号是在 DLL 被加载时由 vsim 进程导出的静态链进去会形成两份定义运气好是重复符号警告运气差是运行期直接崩。SystemC 那条更敏感sccom在底层调用的编译器版本如果和 SC 库的构建版本不一致链接阶段就会出现一堆与异常、线程相关的未解析符号——这类报错看着像是缺库实际是版本错配换回配套的工具链就好。4. 参数怎么定位数、优化、宏与一份可复用的构建脚本编得过不代表跑得对。跨语言边界上的参数设置有几处属于“设错了不报错、结果慢慢歪”的类型尤其是位数和优化等级。这一章把几个关键参数摊开讲最后给一份可以直接抄走的构建脚本把前面所有参数固化下来避免每次手敲命令时漏掉某一项。4.1 位数判定先确认宿主进程是 32 位还是 64 位这一步必须在写任何代码之前做完。判断方法有几种按可靠性排序看安装目录win32/win64子目录、看 vsim 可执行文件的 PE 头、看仿真器启动横幅里的版本串。最直观的是第二种# 直接看 vsim.exe 的 PE 架构 objdump -f C:/modeltech/win32/vsim.exe | head -3 # pei-i386 - 32 位用这份 mingw32 工具链 # pei-x86-64 - 64 位这份工具链不适用确认了位数之后再动手能省掉大量“编译全绿、加载失败”的排查时间。把常见症状和对应结论整理成一张表出问题时对着查现象最可能的原因处理方向加载 DLL 报“找不到指定的模块”DLL 依赖的运行库不在 PATH加-static-libgcc或把工具链 bin 加进 PATH加载报“不是有效的 Win32 应用程序”位数不匹配换 32 位工具链或换 32 位仿真器编译报找不到svdpi.hinclude 路径写错或版本不带该头文件核对安装目录 include 下的实际文件名编译通过、仿真结果全 0参数传递约定或数组维度对不上先用标量函数验证通路再加数组偶发崩溃、换个种子就复现不了C 侧阻塞或跨线程访问 SV 数据保证 DPI 函数纯计算、快速返回4.2 优化等级与宏三个我会固定加上的参数-O2是默认选择但有两个例外。第一只要你在 C 侧加了 printf 排查问题先降到-O0因为优化可能把中间的临时变量整个消掉断点和打印都会失真。第二函数里有大量指针运算和类型转换时务必带上-fno-strict-aliasing。跨语言传结构体和数组指针时编译器基于严格别名假设做的重排产生的问题极难定位——表现是同一个函数单独测没问题放进仿真里结果就是错的而且改一行无关代码就好了典型的玄学。-static-libgcc建议无脑加上。它把 GCC 的运行库静态链进 DLL产物体积大一点但加载时不再依赖外部文件。用了 C 的话再加-static-libstdc道理一样。这两个参数能消掉一大类“换台机器就跑不起来”的问题。第三类是条件编译宏。如果你的 C 代码里有平台分支编译时显式带上-D_WIN32之类的宏别指望编译器自动推断完整。宏没定义带来的后果往往是某段代码被静默跳过程序能跑但行为不对比编译错误难查得多。# 推荐的稳定组合静态运行库 关闭严格别名 显式平台宏 gcc -shared -O2 \ -fno-strict-aliasing \ -static-libgcc -static-libstdc \ -D_WIN32 \ -IC:/modeltech/include \ -Wl,--export-all-symbols \ -o mydpi.dll mydpi.c这一串参数里-O2和-fno-strict-aliasing是性能与正确性的折中-static-libgcc是部署便利性-D_WIN32是行为确定性。四个各管一摊缺哪个都可能在某台机器上出问题。4.3 把参数固化一份能直接抄走的构建脚本手敲命令迟早会漏参数尤其是有多个 C 源文件、要分别编成多个 DLL 的时候。下面的批处理把路径、参数、产物目录都抽成变量改开头几行就能用在别的工程上。#!/usr/bin/env bash # build_dpi.sh —— 在 git-bash 或 WSL 里跑Windows 原生 cmd 请改写成 .bat set -e GCC_DIRD:/tools/modelsim-gcc-4.2.1/bin MTI_INCC:/modeltech/include OUT_DIR./build SRC_DIR./src mkdir -p $OUT_DIR # 逐个源文件编成独立 DLL文件名与源文件同名 for src in $SRC_DIR/*.c; do name$(basename $src .c) echo building $name.dll $GCC_DIR/gcc.exe -shared -O2 \ -fno-strict-aliasing \ -static-libgcc -static-libstdc \ -D_WIN32 \ -I$MTI_INC \ -Wl,--export-all-symbols \ -o $OUT_DIR/$name.dll $src done echo done, artifacts in $OUT_DIRset -e保证任何一步失败就停下不会带着半成品继续往下跑。循环里用basename取文件名产物和源文件一一对应新增源文件不用改脚本。GCC_DIR用正斜杠git-bash 和 MinGW 都能正确识别反斜杠在 bash 里会被当转义符吃掉。脚本跑完build目录下应该有几个 DLL。下一步是在 do 文件里一次性挂上去多个库就用多个-sv_lib顺序不影响加载# run_all.tcl —— 多个 DPI 库一起挂载 vlib work vlog -sv ./tb/tb_top.sv vsim -c -sv_root ./build \ -sv_lib mydpi \ -sv_lib mydpi_extra \ tb_top run -all quit -f-sv_root指定库的搜索根目录后面-sv_lib只写库名不带后缀和路径。这套写法在 CI 里很好用因为路径全由变量控制换机器只改脚本头部两行。5. 避坑五个让我重装过仿真环境的问题下面五条都是真实发生过的顺序按遇到频率排。每条按“现象 → 原因 → 解决”写遇到同类问题时可以直接对着症状定位不用从头排查。5.1 加载时报“找不到指定的模块”但 DLL 明明就在当前目录现象vsim -sv_lib mydpi之后仿真器直接退出提示加载 xxx.dll 失败错误信息里带“找不到指定的模块”。用dir确认过 DLL 存在路径也没写错。原因Windows 的加载器报“找不到模块”指的往往不是目标 DLL 本身而是它依赖的某个 DLL 找不到。MinGW 默认动态链接libgcc_s_dw2-1.dll用了 C 还会拉上libstdc-6.dll这两个文件在工具链的bin目录里。vsim 进程启动时不会自动去那里找于是加载失败。解决两条路优先选第一条。一是编译时加-static-libgcc -static-libstdc把运行库静态链进去产物不再有外部依赖二是把工具链bin目录加进 PATH 再启动 vsim。前者一劳永逸后者适合临时验证。判断 DLL 到底依赖什么在 git-bash 里objdump -p mydpi.dll | grep DLL Name一眼就能看到。5.2 编译一路绿灯仿真结果却全是 0现象DPI 函数调用成功、没报错但返回值恒为 0或者数组求和的结果只有第一个元素对。原因八成是数组传参的形态对不上。SystemVerilog 的input int data[]传到 C 侧是const int*加一个隐含的长度但长度不会自动传必须单独作为参数。另一种常见情况是结构体传参时对齐方式不一致GCC 默认按自然边界对齐SV 侧按 4 字节打包字段偏移错开读出来的就是垃圾数据。解决先用标量函数验证整条通路确认-sv_lib加载、符号解析、调用约定都没问题再逐步加数组和结构体。数组一定显式传长度结构体一定避免跨边界改成传扁平数组或者逐字段传。这条经验我吃过不止一次后来干脆在项目规范里写死跨 DPI 边界的参数只允许基本类型和定长数组。5.3 编译到一半 gcc.exe 消失或者报权限不足现象第一次编译成功过一会儿再编就报找不到 gcc.exe去看目录发现文件真的没了。原因安全软件把旧版 MinGW 的工具链判定为可疑并隔离了。这类工具链年代久、没有数字签名、行为特征又像编译器读写大量文件、生成可执行代码被误杀的概率不低。解决把整个工具链目录加进安全软件的排除列表然后重新解压一份。这只发生在开发机上所以最省事的做法是把它放在一个固定的、已加白的目录里别每次换工程都重新解压到新位置。5.4 换了台机器就编不过报一堆未解析符号现象本机编译正常同事机器上同样的源码、同样的命令链接阶段报一堆undefined reference。原因同事机器的 PATH 里有另一套 MinGW而且排在前面实际生效的是那套。版本不同默认链接的库、异常模型、CRT 假设都不一样症状就是各种符号找不到。解决构建脚本里全部改成绝对路径调用gcc.exe别依赖 PATH。同时在脚本开头加一行$GCC_DIR/gcc.exe -dumpversion打印版本日志里一眼能看到实际用的是哪套。这个习惯是从一次跨机器排查里养成的之后再没在这上面浪费过时间。5.5 中文路径或带空格的路径导致编译中断现象报no such file or directory但文件明明存在路径复制出来粘贴到资源管理器能打开。原因旧版 gcc 对非 ASCII 路径和含空格路径的处理不完善命令行参数在传递过程中被拆分或编码转换出错。带空格的路径没加引号是常见的人为失误中文路径则是工具链本身的限制。解决工程目录、源码目录、输出目录全部用纯英文无空格路径。确实需要放在深层目录的用 8.3 短路径名dir /x能看到绕过去但这属于权宜之计不如一开始就把目录规划好。6. 进阶做一份可切换的工具链目录并用冒烟测试验收装好一份之后很快会碰到第二个需求手上同时有 32 位和 64 位两套仿真环境或者要在新旧两个工程之间来回切。这时候把工具链解压到工程目录里、每个工程一份的做法就开始反噬了——磁盘占用翻倍不说改了一个参数忘了同步到另一份排查起来能让人怀疑人生。我的做法是建一个统一的工具链根目录按“名称-位数-版本”三层命名每份保持原样不动切换靠一个包装脚本完成。目录结构大致是这样D:\tools\ ├── mti-gcc-4.2.1-x32\ # 就是这份 mingw32vc9 包 ├── mti-gcc-4.2.1-x64\ # 64 位环境配的那份 └── switch-gcc.ps1 # 切换脚本切换脚本只做一件事在当前会话里把指定目录顶到 PATH 最前面并打印实际生效的版本方便确认。# switch-gcc.ps1 —— 用法: .\switch-gcc.ps1 x32 param([string]$arch x32) $root D:\tools\mti-gcc-4.2.1-$arch\bin if (-not (Test-Path $root\gcc.exe)) { Write-Error 未找到 $root\gcc.exe请确认目录名 return } $env:PATH $root; ($env:PATH -split ; | Where-Object { $_ -notmatch gcc|mingw }) -join ; $root\gcc.exe -dumpmachine $root\gcc.exe -dumpversion脚本里那句过滤很关键先把 PATH 里所有跟 gcc、mingw 相关的条目全部剔除再把目标目录顶到最前这样不会出现两套工具链交替命中的情况。跑完会打印目标三元组和版本号看到i686-pc-mingw32和4.2.1才算切换成功。光切换还不够得有验收手段。我固定用一个三行的冒烟测试一个返回常量的 DPI 函数一个返回入参加一的函数一个打印字符串的函数。编成 DLL 之后用批处理模式跑一遍检查终端里是否出现预期输出。这套东西跑完不到十秒但能同时验证四件事工具链能编、架构对得上、DLL 能被 vsim 加载、DPI 调用约定正确。任何一项坏了冒烟测试必挂而且挂在哪一步一目了然。验收通过之后再跑真实工程能省掉大量“到底是工具链的问题还是我代码的问题”的互相甩锅。血泪经验是不要在真实工程里第一次验证新工具链那等于把两个变量同时改了出了问题根本没法二分。从那以后我每次换机器、换仿真器版本、或者从别人手里接一份工程都强制先跑一遍这个冒烟测试确认绿灯了再动真实设计。这十秒钟花得很值。希望帮到你。本文还有配套的精品资源点击获取
