CLion与Stm32CubeIDE编译STM32 Bluepill项目固件大小差异原因咨询

可能的原因 #

• 构建模式不一致：CLion默认使用Debug模式构建，该模式会保留完整调试符号、关闭代码优化，直接导致固件体积暴涨；而Stm32CubeIDE默认采用Release模式，开启高级优化的同时会剔除无用符号。哪怕CMakeLists.txt完全一致，IDE的默认构建配置也可能覆盖CMake中的设置。
• 工具链版本/配置差异：两者使用的ARM GCC工具链版本可能不同，新版本工具链的默认编译选项可能更保守（比如优化等级较低），或者关键优化开关未启用。另外CubeIDE可能集成了ST专属的编译补丁，而CLion使用的是通用版工具链。
• 链接器优化未启用：CubeIDE默认会开启-flto（链接时优化）和--gc-sections（垃圾代码回收）这类核心优化，能大量删除未使用的代码和数据。如果CLion的CMake配置中未明确添加这些选项，固件体积必然会大幅增加。
• 调试信息处理不同：CLion默认将调试信息（如DWARF）嵌入最终的ELF固件中，而CubeIDE默认会把调试信息拆分到单独文件（比如.elf.debug），Flash镜像里仅保留可执行代码。

解决建议 #

• 切换到Release构建模式：在CLion顶部的构建配置下拉菜单中选择Release，或者在CMake配置里直接设置CMAKE_BUILD_TYPE=Release。
• 统一工具链版本：安装与Stm32CubeIDE相同版本的ARM GCC工具链，然后在CLion的File > Settings > Build, Execution, Deployment > Toolchains中指定该工具链的路径。
• 强制开启链接优化：在CMakeLists.txt中添加以下配置（将your_target_name替换为项目实际目标名称）：

  # 启用链接时优化
  set(CMAKE_INTERPROCEDURAL_OPTIMIZATION_RELEASE ON)
  # 开启垃圾代码回收
  target_link_options(your_target_name PRIVATE -Wl,--gc-sections)
  # 标记可回收的代码/数据段
  target_compile_options(your_target_name PRIVATE -fdata-sections -ffunction-sections)
  

• 分离调试信息：通过objcopy生成不含调试信息的Flash镜像，在CMake中添加自定义命令：

  add_custom_command(TARGET your_target_name POST_BUILD
                     COMMAND ${CMAKE_OBJCOPY} -O ihex --only-section=.text --only-section=.data $<TARGET_FILE:your_target_name> ${PROJECT_NAME}.hex
                     COMMAND ${CMAKE_OBJCOPY} -O binary --only-section=.text --only-section=.data $<TARGET_FILE:your_target_name> ${PROJECT_NAME}.bin)
  

  生成的.hex或.bin文件就是精简后的Flash镜像，体积会和CubeIDE的输出一致。
• 对比编译命令找差异：查看CLion Build窗口的详细编译/链接命令，和CubeIDE的输出做对比，找出不一致的选项后在CMakeLists.txt中统一配置。

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