linux - GDB在远程调试期间挂起，库版本不匹配

Question

我正在使用linux，正在尝试远程调试程序。

我从.xinitrc使用以下命令在目标上启动gdbserver

gdbserver localhost:9134 /root/game/game

在我运行在virtualbox vm中的本地PC上，我使用以下命令从gdb连接到目标

target remote 192.168.1.20:9134

它连接良好。
我可以在主设置断点

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/)的主机上的根目录中扩展，其中包含创建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&\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，而不是指向目标具有的副本。也许我没有正确设置它们，但是我尝试使用 set env在gdb中设置它们，并在命令行上设置它们并导出它们，但是没有效果。我还尝试将libc从主机计算机放到目标计算机上，它甚至无法启动，它在libc中出现段错误。
那么，如何使gdb加载不同的库？

更新6:
因此，我使用目标系统的磁盘镜像作为基础创建了一个可启动的USB密钥。我对其进行了最小的更改，以使其能够在标准PC上运行，并向其中添加了gdb和gdb的必需库。所以现在，ibc在主机和目标计算机上都相同，但仍然卡在我身上。

最后。虽然我知道gdb 6.8过去可以工作，但我无法弄清楚配置。将gdb和gdbserver都升级到7.12后，它可以工作了。

Answer 1

Upgrading versions, while a very large headache, could be possible but probably should not be necessary...

这是正确的选择。正因为如此，您遇到的所有其他问题。

I've tried this in another virtual machine and I even built a fresh dedicated linux install (so no vm), rebuilt the software, and I get the same behavior. So it appears the issue is probably on the target machine's configuration.

您应该在与试图将代码部署到的系统相同的版本，体系结构等上进行构建。

But then when I try to set breakpoints, I get Error accessing memory address 0xb5eb60: Input/output error.

每 this answer，

Can be caused by 32/64 bit mixups. Check, for example, that you didn't attach to a 32-bit binary with a 64-bit process' ID, or vice versa.

I also tried putting the libc from the host computer onto the target machine, and it won't even boot, it gets a segfault in libc.

不要那样做如您所知，它将无法正常工作。

So how do I get gdb to load different libraries?

对于 this question，您可以使用 LD_LIBRARY_PATH。