如何在不传输符号表/可执行文件的情况下远程调试大体积Core Dump？

场景：客户持有几十到上百GB的core dump文件，调试任务为P1紧急级别，传输文件耗时过长，需在本地完成分析。可远程向客户系统发送GDB命令，但无法在客户侧部署源码或符号表。

核心疑问：

1. 能否通过两端GDB会话——客户侧加载core dump输出backtrace地址，本地侧加载可执行文件与符号表——将客户侧的地址导入本地GDB，完成地址到符号、源码位置的映射，生成详细回溯结果？
2. 是否存在其他无需向客户侧提供可执行文件与符号表的远程调试core dump方案？

一、你提出的跨GDB会话地址映射方案：完全可行 #

这种思路本质是利用本地符号表对客户侧获取的指令地址做离线解析，具体实现步骤如下：

1. 从客户侧提取有效地址 #

让客户执行bt full（而非仅bt），获取所有栈帧的指令地址（即#N 0xXXXX...中的十六进制值），同时必须确认：客户侧core dump对应的可执行文件与你本地的是完全一致的编译产物（包括编译选项、版本、架构，否则地址映射会失效）。

注意：客户侧bt输出中的无效地址（如0x0000000700000000、0x0000000000000000）是栈上的无效值，可直接忽略。

2. 本地GDB中解析地址 #

方法1：直接使用GDB命令解析

在本地加载可执行文件与符号表后，对每个有效地址执行：

info symbol 0x000055e3eb1b92dd

会直接返回符号名与所属段信息：

print_list in section .text of /path/to/your/executable

再执行：

list *0x000055e3eb1b92dd

可查看该地址对应的源码行：

0x55e3eb1b92dd is in print_list (broken_linked_list.c:52).
51	    }
52	    printf("Element %d: %d\n", i, list[i].value);
53	}

方法2：修复你的Python脚本实现

你的原脚本问题在于误用lookup_global_symbol——该函数用于通过符号名查找，而非地址。正确实现如下：

import gdb

def map_addresses_to_symbols(addresses):
    mapped_data = {}
    for addr in addresses:
        try:
            # 通过地址获取对应函数块与源码信息
            addr_val = gdb.Value(addr).cast(gdb.lookup_type('void').pointer())
            block = gdb.block_for_address(addr_val)
            if block and block.function:
                func_name = block.function.name
                line = block.line
                filename = block.symtab.filename
                mapped_data[addr] = f"{func_name} at {filename}:{line}"
            else:
                #  fallback到info symbol命令输出
                sym_info = gdb.execute(f"info symbol {hex(addr)}", to_string=True).strip()
                mapped_data[addr] = sym_info
        except gdb.error as e:
            mapped_data[addr] = f"Unresolved: {str(e)}"
    return mapped_data

# 客户侧获取的有效地址
received_data = [0x000055e3eb1b92dd, 0x000055e3eb1b91db]

mapped_info = map_addresses_to_symbols(received_data)
for addr, info in mapped_info.items():
    print(f"Address: {hex(addr)} -> {info}")

执行后输出示例：

Address: 0x55e3eb1b92dd -> print_list at broken_linked_list.c:52
Address: 0x55e3eb1b91db -> main at broken_linked_list.c:19

二、其他无需传输core dump/部署符号表的方案 #

1. GDB远程调试模式（gdbserver） #

让客户在其机器上启动gdbserver加载core dump：

gdbserver --multi :1234 --core=/path/to/large/core.dump

你在本地启动GDB，加载可执行文件与符号表，然后连接到客户侧的gdbserver：

target remote <客户IP>:1234

此时你可以直接在本地GDB中执行bt、info registers等命令，所有符号解析在本地完成，客户侧仅负责提供core dump的内存数据，无需部署符号表或源码。

注意：这种方式需要客户侧开放端口，网络延迟会影响调试效率，但无需传输大文件。

2. 提取core dump的栈片段 #

如果仅需分析栈回溯，可让客户执行GDB命令提取栈的关键部分：

set logging file stack_dump.txt
set logging on
bt full
info registers
set logging off

将生成的stack_dump.txt（通常仅几KB）发送给你，再用本地符号表解析其中的地址，与第一种方案逻辑一致。

关键前提 #

无论哪种方案，必须保证：

• 你本地的可执行文件与客户侧生成core dump的可执行文件是完全相同的编译版本（MD5/SHA1一致），否则地址与符号的映射会完全错误。
• 若涉及动态链接库，你本地还需要对应版本的.so文件与符号表（客户侧无需部署，仅需你本地有）。

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