编辑：我似乎搞错了，回溯在Linux上的任何地方都能很好地工作——只有当从ubuntu上的gdb到远程窗口进行远程调试时，在msvcrt中输入一个内存分配函数后，堆栈竞争才会被彻底破坏。。。该死的微软
64位和32位窗口都会发生这种情况，所以我不确定这是否与展开信息有关
编辑：添加-g3和-Og似乎有助于解决某些程序中的部分问题，但其他程序中的问题仍然存在，无法在此处发布其来源，因为这是我公司的IP——对不起
背景
我用gcc编译ubuntu->ubuntu，用mingw编译ubuntu->windows。
我创建了一个跨平台(linux+windows(内存跟踪&泄漏检测库，它在第一条指令上用程序集字节补丁钩住malloc/calloc/realloc/free(而不是IAT/PLT钩住(。
钩子重定向到一个门，该门检查钩子是否在当前线程中启用，如果启用，则重定向到内存跟踪钩子函数，否则，如果该线程禁用了钩子，则只重定向到实际函数的蹦床。
这个库工作得很好，可以在linux/windows上检测泄漏(可能在mac上也可以，但我没有(。
我使用该库以编程方式检测代码中的泄漏，我可以在内存分配例程上安装回调，并在回调中以编程方式引发断点(通过循环并等待调试器附加，然后执行asm("int3"((，这样我就可以在程序处于泄漏内存的调用中时附加到程序。
在我尝试从回调中查看回溯之前，一切都很好，我知道这可能是因为展开信息可能不再与我的堆栈匹配，因为我通过插入的钩子例程插入了新的帧和数据。
编辑：如果我错认为放卷信息与堆栈不匹配是不正确回溯的原因，请纠正我！
问题
有什么小技巧可以让GDB从我的钩子回调中正确地重建回溯吗？
我知道我可以用libdwarf或其他东西手动浏览和编辑解除信息，但我想这会非常麻烦和庞大。
所以我想知道我是否可以做一个黑客或欺骗，欺骗GDB正确重建回溯？
如果没有简单的技巧或窍门，那么我有什么选择来解决这个问题？
编辑：只是为了清理所有东西的确切调用顺序：
program
V
malloc
V
hook_malloc -> hooks are disabled -> return malloc trampoline -> real malloc > program
V
hooks are enabled
V
Call original malloc -> malloc trampoline -> real malloc -> returns to hook
V
Record memory size/info etc from malloc
V
Call user defined callback -> **User defined callback* -> returns to hook
V
return to program
这是"用户定义的回调"，我想在这里捕获回溯
显然这也是GDB Windows的问题？？在回溯中
解决方案是简单地将-g3添加到mingw编译标志和viola我有未中断的回溯！
编辑：无论如何，这不是全部答案。这个修复程序似乎适用于一些测试程序，但其他程序仍然显示不正确的回溯，如：
(gdb) bt
#0 malloc_callback (s=38, rv=0x2c5058) at test_dll.c:729
#1 0x000000000040731d in hook_malloc_raw (file=0x410ea1 <__FUNCTION__.63079+55> "", function=0x410ea1 <__FUNCTION__.63079+55> "", line=0, s=38, rv=8791758343065)
#2 0x0000000000407367 in hook_malloc (s=38)
#3 0x000007fefda20b9e in ?? ()
#4 0x0000000000000026 in ?? ()
#5 0x0000000000410ea1 in __FUNCTION__.63079 ()
#6 0x0000000000000000 in ?? ()
很明显，帧#4实际上不是一个堆栈帧，我不确定为什么帧#5被标记为"__FUNCTION __.63079"。
编辑2：如果人们要投反对票，至少要留言说明的原因