我正在使用linux，正在尝试远程调试程序。
我在目标上启动 gdbserver，从 .xinitrc 使用
gdbserver localhost:9134 /root/game/game
在我的本地电脑上，我在虚拟盒子虚拟机中运行，我使用
target remote 192.168.1.20:9134
它连接良好。 我可以在主节点设置断点
b main
然后我可以继续，它会在那里破裂。我可以单步一步，直到它到达调用 SDL_Init()，它永远不会返回到 gdb。 如果我不单步SDL_Init而是在程序中进一步设置断点，程序将启动并正常运行(因此它已经过了SDL_Init)。但是当它到达断点时，它会在目标计算机上冻结，并且我的本地计算机上的 gdb 永远不会显示提示。整个事情挂起，必须重新启动。但是，它并没有完全冻结，因为鼠标指针仍然在目标上移动，您可以ping它，但是gdb连接不再有效。因此，图形系统似乎以某种方式干扰了这一点，因为图形系统初始化之前的断点确实有效，但在之后就不工作了。
我尝试将remotetimeout设置设置为 500 秒，它表现出相同的行为。当我从本地PCping远程目标时，报告的时间约为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 窗口甚至无法启动。
更新#4：
我尝试从主机上目标文件系统副本的根目录启动 gdb (/fw_dev/fgs/cf/initrd/expand)，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&266b340230321b") 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，而不是指向目标具有的副本。也许我没有正确设置它们，但我尝试使用set env在 gdb 中设置它们，并在命令行上设置它们并导出它们，但没有效果。我还尝试将 libc 从主机放到目标机器上，它甚至无法启动，它在 libc 中出现段错误。 那么如何让 gdb 加载不同的库呢？
更新#6：
因此，我使用目标系统的磁盘映像作为基础制作了一个可启动的USB密钥。我对它进行了最小的更改，使其在标准PC上运行，并向其添加了gdb和gdb的必要库。所以现在，ibc 在主机和目标机器上都是一样的，它仍然挂在我身上。
最后。虽然我知道 gdb 6.8 过去有效，但我无法弄清楚配置。将 gdb 和 gdbserver升级到7.12 后，它就可以工作了。
升级版本虽然非常令人头疼，但可能是可能的，但可能没有必要......
这是正确的选择。您遇到的所有其他问题都是因为这个。
我已经在另一个虚拟机中尝试过这个，我什至构建了一个全新的专用 linux 安装(所以没有 vm)，重建了软件，我得到了相同的行为。因此，问题似乎可能出在目标计算机的配置上。
您应该在与尝试将代码部署到的系统相同的版本、体系结构等上构建。
但是当我尝试设置断点时，我收到访问内存地址0xb5eb60时出错：输入/输出错误。
根据这个答案，
可能是由 32/64 位混淆引起的。例如，检查您是否没有附加到具有 64 位进程 ID 的 32 位二进制文件，反之亦然。
我还尝试将 libc 从主机放到目标机器上，它甚至无法启动，它在 libc 中出现段错误。
别这样。正如您发现的那样，它不起作用。
那么如何让 gdb 加载不同的库呢？
根据这个问题，您可以使用LD_LIBRARY_PATH.
这里有一些有趣的建议。您是否尝试过将 gdbserver 连接到 strace 以查看挂起期间正在发生什么样的活动？正如其他人所说 - 这可能是进一步解决问题的好方法。 您可以在目标计算机上使用以下命令执行此操作：
strace -p `pidof gdbserver`
此外，向gdbserver发送CONT信号在挂起时可能会有所帮助：
kill -CONT `pidof gdbserver`