Question

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

我使用

从.xinitrc启动目标上的gdbserver

gdbserver localhost:9134 /root/game/game

在我运行在virtualbox虚拟机中的本地PC上，我使用以下命令从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窗口甚至无法启动。

更新＃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

升级版本虽然有很大的麻烦，但有可能，但可能没有必要...

这是正确的选择。您遇到的所有其他问题都是由于这个原因。

我已经在另一个虚拟机上尝试了这个，甚至还构建了一个全新的专用linux安装程序（因此没有vm），重新构建了该软件，并且得到了相同的行为。因此看来问题可能出在目标计算机的配置上。

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

但是当我尝试设置断点时，访问内存地址0xb5eb60时出错：输入/输出错误。

每this answer，

可能是由32/64位混合引起的。例如，检查您是否没有附加到具有64位进程ID的32位二进制文件，反之亦然。

我还尝试将libc从主机计算机放到目标计算机上，它甚至无法启动，它在libc中出现段错误。

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

那我如何让gdb加载不同的库？

每this question，您可以使用LD_LIBRARY_PATH。

Answer 2

Here are一些有趣的建议。您是否尝试将gdbserver附加到strace，以查看挂起期间正在进行的活动是什么？正如其他人所说，这可能是进一步解决问题的好方法。您可以在目标计算机上使用以下命令来做到这一点：

strace -p `pidof gdbserver`

在挂起时也向CONT发送gdbserver信号可能会有所帮助：

kill -CONT `pidof gdbserver`

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

2 个答案: