4、功能裁剪原理：宏定义控制、模块化编译与条件编译

说到密码库裁剪，我见过不少团队直接把整个库扔进嵌入式项目，结果Flash爆了、RAM不够、编译时间长得能喝杯咖啡。其实说白了，密码库的裁剪就三板斧：宏定义控制、模块化编译、条件编译。这三招用好了，库的体积能砍掉一半以上。

4.1 宏定义控制：MBEDTLS_CONFIG_FILE 的妙用

MbedTLS 的裁剪核心是 mbedtls_config.h。你想想看，这个文件里全是 #define MBEDTLS_XXX 这样的宏。注释掉一个宏，对应的功能就从编译中消失了。

我个人习惯的做法是：不直接修改默认的 mbedtls_config.h，而是用 MBEDTLS_CONFIG_FILE 这个宏来指定自己的配置文件。这样能保持原始库的完整性，方便后续升级。

// 在编译命令中指定自定义配置文件
// GCC 示例：
gcc -DMBEDTLS_CONFIG_FILE=\"my_config.h\" -c my_program.c

// 或者在 Makefile 中：
CFLAGS += -DMBEDTLS_CONFIG_FILE=\"my_config.h\"

我在一个IoT项目里遇到过这种情况：设备只需要 AES-128-CBC 和 SHA-256，但默认配置打开了 RSA、ECDH、GCM 等一堆功能。通过自定义配置文件，我把编译出来的库从 180KB 砍到了 35KB。

4.2 模块化编译：--enable/--disable 的实战

如果你用的是 OpenSSL 或者 WolfSSL，它们的 configure 脚本提供了 --enable-xxx 和 --disable-xxx 选项。这比手动改宏要方便得多。

选项	说明	典型场景
--disable-rsa	禁用 RSA 算法	只用 ECC 的设备
--enable-ecc	启用椭圆曲线密码	资源受限的 IoT 节点
--disable-tls1_3	禁用 TLS 1.3	兼容旧协议的系统
--enable-small	启用体积优化模式	Flash 小于 256KB 的设备

# WolfSSL 裁剪示例：只保留 AES 和 SHA
./configure --disable-rsa --disable-dh --disable-ecc \
            --disable-chacha --disable-poly1305 \
            --enable-aes --enable-sha \
            --enable-small --enable-singlethreaded

make clean && make

嗯，这里要注意：--enable-small 这个选项会牺牲一些性能来换取体积。如果你的 CPU 主频很低，得权衡一下。

4.3 条件编译与代码移除

条件编译是 C 语言的老本行了。密码库内部大量使用 #if defined(MBEDTLS_XXX) 来控制代码段是否编译。但光靠这个还不够，你还需要配合 链接器优化 来真正移除未使用的代码。

// MbedTLS 内部的条件编译示例
#if defined(MBEDTLS_AES_C)
int mbedtls_aes_setkey_enc(mbedtls_aes_context *ctx,
                           const unsigned char *key,
                           unsigned int keybits) {
    // AES 密钥设置实现
    // ...
    return 0;
}
#endif /* MBEDTLS_AES_C */

但条件编译有个陷阱：即使你注释了宏，如果其他模块引用了这个函数，链接器还是会把它拉进来。所以真正的代码移除需要三步走：

1. 宏定义层：在配置文件中关闭不需要的功能
2. 编译层：使用 -ffunction-sections -fdata-sections 让每个函数独立成段
3. 链接层：使用 --gc-sections 垃圾回收未引用的段

# GCC 编译选项示例：彻底移除未使用代码
CFLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections

# 完整编译命令
arm-none-eabi-gcc $(CFLAGS) -c my_program.c
arm-none-eabi-gcc $(LDFLAGS) -o firmware.elf *.o

我做过一个对比实验：同样的代码，不加这两个选项编译出来 120KB，加上之后只有 68KB。差距就是这么明显。

4.4 裁剪决策流程

下面这张图是我在实际项目中总结的裁剪决策流程，你可以照着这个思路来操作：

4.5 实战检查清单

最后，我整理了一份裁剪时的检查清单，每次做裁剪我都会对着过一遍：

• 功能清单：列出项目真正需要的算法和协议，一个都不要多
• 依赖分析：检查每个模块的依赖关系，避免裁剪后链接失败
• 编译选项：确认启用了 -ffunction-sections 和 --gc-sections
• 体积对比：裁剪前后对比 .text/.data/.bss 段的大小
• 功能测试：裁剪后跑一遍所有功能测试用例
• 回归测试：确保裁剪没有破坏已有功能