问题：FreeRTOS环境下自定义malloc为何未被printf调用？

核心原因 #

1. C++名字修饰导致自定义malloc的符号与标准库的C符号不匹配，无法覆盖。
2. 链接顺序错误，标准库的malloc实现优先于自定义代码被链接。
3. 部分标准库（如newlib）的malloc实际调用线程安全的_malloc_r，而非直接调用malloc。

具体解决步骤 #

1. 强制C语言链接，避免名字修饰 #

C++会对函数名进行修饰，而标准库的malloc是C语言符号，必须用extern "C"包裹自定义实现，确保符号一致：

extern "C" {
void *malloc(size_t size) {
    return tlsf_malloc(size);
}

// 同步覆写free，避免内存泄漏
void free(void *ptr) {
    tlsf_free(ptr);
}
}

2. 使用链接包裹（wrap）强制拦截malloc调用 #

通过GCC链接选项--wrap=malloc，让所有对malloc的调用转向自定义的__wrap_malloc函数：

extern "C" {
void *__wrap_malloc(size_t size) {
    return tlsf_malloc(size);
}

// 同理拦截free
void __wrap_free(void *ptr) {
    tlsf_free(ptr);
}
}

编译/链接时添加选项：

-Wl,--wrap=malloc -Wl,--wrap=free

3. 覆写newlib的线程安全分配函数（若使用newlib） #

如果项目使用newlib标准库，其malloc实际是封装了_malloc_r（线程安全版本），需要直接覆写该函数：

extern "C" {
#include <reent.h>

void *_malloc_r(struct _reent *r, size_t size) {
    (void)r; // 忽略线程环境参数，若需要可适配
    return tlsf_malloc(size);
}

void _free_r(struct _reent *r, void *ptr) {
    (void)r;
    tlsf_free(ptr);
}
}

4. 调整链接顺序，确保自定义代码优先 #

将包含自定义malloc实现的源文件（或目标文件）放在链接命令的最前端，让编译器优先选择强符号：

# 示例链接命令：先链接自定义malloc的目标文件，再链接其他代码和标准库
arm-none-eabi-g++ malloc_override.o other_files.o -mcpu=cortex-m7 ... -lc -lm

5. 验证符号是否被正确覆盖 #

使用arm-none-eabi-nm工具检查最终可执行文件的符号，确认自定义malloc被正确链接：

arm-none-eabi-nm your_project.elf | grep malloc

若输出中malloc对应的是T（强符号，位于文本段），说明覆盖成功；若为W（弱符号），则需检查链接顺序或符号匹配问题。

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