【发布时间】：2019-11-08 18:35:49
【问题描述】：
我正在使用 linux 并尝试远程调试程序。
我在目标上启动 gdbserver，从 .xinitrc 使用
gdbserver localhost:9134 /root/game/game
在我的本地电脑上，我在 virtualbox vm 中运行，我从 gdb 连接到目标
target remote 192.168.1.20:9134
它连接良好。 我可以使用
在 main 处设置断点b main
然后我可以继续，它会在那里中断。我可以单步执行，直到调用 SDL_Init()，它永远不会返回到 gdb。 如果我不单步执行 SDL_Init，而是在程序中进一步设置断点，程序将启动并正常运行（因此它通过 SDL_Init）。但是当它到达断点时，它会在目标机器上冻结，而我本地机器上的 gdb 永远不会显示提示。整个事情挂起，必须重新启动。但是，它并没有完全冻结，因为鼠标指针仍然在目标上移动并且您可以 ping 它，但是 gdb 连接不再起作用。因此，图形系统似乎以某种方式干扰了这一点，因为图形系统 init 之前的断点确实有效，但之后没有。
我尝试将 remotetimeout 设置为 500 秒，它表现出相同的行为。当我从本地电脑 ping 远程目标时，报告的时间大约是 0.3 到 0.4 毫秒。所以这似乎并没有什么不同，但我不排除我的任何其他错误配置的网络设置。
它在一个遗留系统上（但是嘿，它仍然赚钱），gdbserver 版本 6.8-19.fc10 和 gdb 版本 6.8-29.fc10。升级版本虽然令人头疼，但可能是可能的，但可能不是必需的（我对我的电脑所做的任何升级也必须对州监管机构的系统进行，因为他们使用 gdb 设置进行测试，但它是不是不可能）。在我接手该项目之前，远程调试过去一直在工作，之前从事过它的人都没有问过。 gdbserver 版本确实有效，因为我使用的是以前使用的确切程序。
更新 1：
我将主机上的 gdb 版本更新为 7.0.1 版本，它仍然表现出相同的行为。我不能做第 8 版，因为它需要 C++11 编译器，而旧系统在那个时间之前。
更新 2：
我已经在另一台虚拟机上试过这个，我什至构建了一个全新的专用 linux 安装（所以没有 vm），重建了软件，我得到了相同的行为。所以看来问题可能出在目标机器的配置上。
更新 3：
我挖出一条串行电缆，最后通过串行进行了远程调试设置。它仍然不起作用，但它给了我更多的错误信息。我得到了错误
gdbserver: error initializing thread_db library: version mismatch between libthread_db and libpthread
我认为这是有道理的，因为我的断点在图形系统初始化后停止工作，这涉及创建一些线程。在谷歌搜索该错误后，我尝试使用set solib-absolute-prefix、set solib-search-path 和set sysroot 到目标机器上文件系统副本的主机上的根目录（在主机上，即 /fw_dev/ fgs/cf/initrd/expand，其中包含生成 initrd 的文件系统）
但是当我尝试设置断点时，我得到Error accessing memory address 0xb5eb60: Input/output error. 我也尝试将这些变量设置到 lib 子目录，这也不起作用。我还尝试将本地线程库从主机的/lib 目录复制到目标上的/lib，但随后 x windows 甚至无法启动。
更新 #4：
我尝试从主机上目标文件系统副本的根目录 (/fw_dev/fgs/cf/initrd/expand) 启动 gdb，但 gdb 仍然挂在断点上，但我不再收到有关 libthread_db 和 libpthread 不匹配的错误消息，所以回到绘图板。
更新 #5
也许我已经到了应该问这个单独问题的地方，但是我编译了 gdb，然后自行运行 gbd。然后使用file将其设置为主机上的程序，设置远程目标，设置我的断点然后运行continue。当我到达断点时，gdb 一如既往地挂起。但是现在当我在 gdb 中按 ctrl-c 时，我得到了这个回溯
#0 0x00110416 in __kernel_vsyscall ()
#1 0x00b3f39d in ___newselect_nocancel () from /lib/libc.so.6
#2 0x08203b9a in ser_base_wait_for (scb=0x96a2930, timeout=1) at ser-base.c:206
#3 0x08203c89 in do_ser_base_readchar (scb=0x96a2930, timeout=-1) at ser-base.c:256
#4 0x08204046 in generic_readchar (scb=0x96a2930, timeout=-1, do_readchar=0x8203c60 <do_ser_base_readchar>) at ser-base.c:326
#5 0x082040b0 in ser_base_readchar (scb=0x96a2930, timeout=-1) at ser-base.c:391
#6 0x081ecac2 in serial_readchar (scb=0x96a2930, timeout=-1) at serial.c:376
#7 0x080c4357 in readchar (timeout=<value optimized out>) at remote.c:5922
#8 0x080c5e35 in getpkt_or_notif_sane_1 (buf=0x839f140, sizeof_buf=0x839f144, forever=1, expecting_notif=0) at remote.c:6440
#9 0x080d1e0a in getpkt_sane (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:6534
#10 remote_wait_as (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:4736
#11 remote_wait (ops=0x839f180, ptid=..., status=0xbffff388, options=0) at remote.c:4843
#12 0x08184d4b in target_wait (ptid=..., status=0xbffff388, options=0) at target.c:2098
#13 0x0815daf2 in wait_for_inferior (treat_exec_as_sigtrap=0) at infrun.c:2028
#14 0x0815ddd4 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT, step=0) at infrun.c:1652
#15 0x08153729 in continue_1 (all_threads=0) at infcmd.c:668
#16 0x08153ea2 in continue_command (args=0x0, from_tty=0) at infcmd.c:760
#17 0x0808e9e8 in execute_command (p=0x83b89a1 "", from_tty=0) at top.c:453
#18 0x0816b028 in command_handler (command=0x83b89a0 "c") at event-top.c:511
#19 0x0816bd5a in command_line_handler (rl=0x8ce83e8 "\340&\266\b\340\230\321\b") at event-top.c:736
#20 0x0822d5a5 in rl_callback_read_char () at callback.c:205
#21 0x0816b17b in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:178
#22 0x0816ac54 in handle_file_event (data=...) at event-loop.c:812
#23 0x08169e6b in process_event () at event-loop.c:394
#24 0x0816aba4 in gdb_do_one_event (data=0x0) at event-loop.c:459
#25 0x0816500b in catch_errors (func=0x816a950 <gdb_do_one_event>, func_args=0x0, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#26 0x080f072a in tui_command_loop (data=0x0) at ./tui/tui-interp.c:153
#27 0x08165684 in current_interp_command_loop () at interps.c:291
#28 0x0808653b in captured_command_loop (data=0x0) at ./main.c:226
#29 0x0816500b in catch_errors (func=0x8086530 <captured_command_loop>, func_args=0x0, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#30 0x08085ecc in captured_main (data=0xbffff7a4) at ./main.c:902
#31 0x0816500b in catch_errors (func=0x80853d0 <captured_main>, func_args=0xbffff7a4, errstring=0x82ccc3d "", mask=6) at exceptions.c:510
#32 0x080851d1 in gdb_main (args=0xbffff7a4) at ./main.c:911
#33 0x08085195 in main (argc=128, argv=0x0) at gdb.c:33
所以 gdb 似乎挂在 __kernel_vsyscall() 中。在主机上的 /lib 目录中的 libc.so.6 上和目标上的 libc.so.6 上进行差异显示差异。我试过使用 LD_PRELOAD 和 LD_LIBRARY_PATH 但回溯总是显示 /lib/libc.so.6 而不是指向目标拥有的副本。也许我没有正确设置它们，但我尝试在 gdb 中使用set env 设置它们，并在命令行上设置它们并导出它们，但没有效果。我还尝试将主机上的 libc 放到目标机器上，它甚至无法启动，它在 libc 中出现了段错误。
那么如何让 gdb 加载不同的库呢？
更新 #6：
所以我使用目标系统的磁盘映像作为基础制作了一个可启动的 USB 密钥。我对其进行了最小的更改以使其在标准 PC 上运行，并向其中添加了 gdb 和 gdb 的必需库。所以现在，主机和目标机器上的 ibc 是相同的，它仍然挂在我身上。
决赛。虽然我知道 gdb 6.8 过去可以工作，但我无法弄清楚配置。将 两个 gdb 和 gdbserver 升级到 7.12 后，它可以工作了。
【问题讨论】：
-
您使用的是什么 Linux 发行版？另外，你运行的是什么内核版本？
-
目标上的内核 2.6.27.5-117.fc10.i686。它是从 Fedora 派生的，但它确实被剥离并使用了 BusyBox。这是一个大型嵌入式系统，虽然它使用或多或少的普通主板，但增加了硬件（GPIO、NVRAM、电池备份入侵检测等）。主机使用具有相同内核的 32 位 Fedora 10。
-
dmesg怎么样？里面有什么有趣的吗？另外，系统有多少内存？ -
挂起后，我无法在目标上运行dmesg，因为gui已启动，我无法用键盘杀死它。我试图将 sshd 放在它上面，以为它挂起后我可以远程进入目标，但它更多的是库问题并且它存在段错误。
-
可以不用GUI启动，然后手动启动吗？
标签： linux networking gdb sdl remote-debugging