使用gdbserver調試共享庫

Question

我在目標和CodeSourcery IDE上使用gdbserver。我的硬件是一個omap3530的軟件。

我可以在主應用程序中單步執行代碼，但是如果我嘗試進入共享庫中的函數，我會獲取內存地址並終止調試器。

這是我的圖書館被編譯並複製到目標系統上的/ lib文件夾。（它確實有調試符號）我已經嘗試使用.gbdinit文件設置solib絕對前綴/ lib目錄

下面是從gdb的跟蹤警告：

903,056 13-gdb-set sysroot-on-target /lib 
903,065 13^done 
903,065 (gdb) 
903,065 14-target-select remote 192.168.1.101:2345 
903,114 =thread-group-started,id="i1",pid="42000" 
903,114 =thread-created,id="1",group-id="i1" 
903,115 15-list-thread-groups --available 
903,120 16-list-thread-groups 
903,128 &"warning: Unable to find dynamic linker breakpoint function.\nGDB will be unable to debug shared library initializers\nand track explicitly loaded dynamic code." 
903,128 &"\n" 

導致

903,395 &"Error while mapping shared library sections:\n" 
903,397 &"/lib/libCoreLib.so: Invalid argument.\n" 
903,399 =library-loaded,id="/lib/libCoreLib.so",target-name="/lib/libCoreLib.so",hostname="/lib/libCoreLib.so",low-address="0x0",high-address="0x0",symbols-loaded="0",thread-group="i1" 

Answer 1

您可以使用安裝在主機上的庫調試，只要debugg機器也是開發機器。在這種情況下，您使用set sysroot而不是set sysroot-on-target。例如：

set sysroot /home/username/.../rootfs/ 

其中/home/username/.../rootfs/包含您的目標文件系統

的副本我想你也應該指定在調試時遇到/，而不是/lib

Answer 2

類似的問題。調試掛斷了。配置如下

主機：Ubuntu的12.04LTS

IDE：Eclipse的開普勒

目標：Beaglebone黑色/ ARM A8

OS：埃

個解決方案

更新庫和包括

選擇在Eclipse

• C/C++常規>路徑和符號>（包括TAB）GNU C>添加>文件 的項目屬性系統> /> usr從/ usr/lib/gcc/i686-linux-gnu/4/6 /包括 到/ usr/arm-linux-gnueabi/include

• C/C++常規>路徑和符號>（包括TAB）GNU C++> Add>
  文件系統> /> usr /usr/arm-linux-gnueabi/include/c++/4.6。3 /臂-Linux的gnueabi

• C/C++常規>路徑和符號>（庫路徑TAB）>添加>文件 系統> /> USR的/ usr /臂-Linux的gnueabi/lib中

Answer 3

好日子，

如果「調試文件目錄」在GDB變量設置錯誤， 則報告的錯誤消息包括： 警告：無法找到動態鏈接程序斷點功能。

目標的根文件系統在 的/ opt/ARM-Linux的gnueabihf-根文件位於我的PC主機上

以下兩條命令幫助我獲得遠程調試使用GDB通過gdbserver的工作 （V7 .11.1）：

set debug-file-directory /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug 
set sysroot /opt/arm-linux-gnueabihf-rootfs 

我已經注意到，如果「SYSROOT」在路徑結尾的斜線，然後 GDB無法連接到遠程目標後使用it.You會看到這個（不正確的輸出） ：

Reading /lib/ld-linux-armhf.so.3 from remote target... 

或

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3...(no debugging symbols found)...done 

而不是正確的輸出：

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3... 
Reading symbols from /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug/ 
lib/arm-linux-gnueabihf/ld-2.23.so...done. 

問候， Frikkie THIRION

Answer 4

使用調試符號目標

這是最簡單的方法來開展工作，並且當您開發一個特定的共享庫時它特別有用。

首頁複印測試可執行文件和共享庫的目標與調試信息：

• 檢查與readelf ----debug-dump=decodedline libmyib.so：How can I tell if a library was compiled with -g?
• 我建議用在主機NFS服務器，使編譯後的輸出變彙編後自動上傳

然後上目標：

gdbserver --multi :1234 ./executable_name 

主持人：

arm-linux-gnueabihf-gdb -q -nh \ 
    -ex "target extended-remote target-hostname-or-ip:1234" \ 
    -ex "file ./executable_name" \ 
    -ex 'tb main' \ 
    -ex 'c' \ 
    -ex 'set solib-search-path .' 

sharedlibrary libmylib.so也適用。

我遇到的問題是gdbserver停止在動態加載器，在main之前，並且動態庫尚未加載，所以GDB不知道符號在內存中的位置。

GDB似乎有一些機制來自動加載共享庫符號，如果我編譯爲主機，並在本地運行gdbserver，則不需要運行到main。但是在ARM目標上，這是最可靠的事情。

目標gdbserver 7.12-6，主機arm-linux-gnueabihf-gdb 7.6.1來自Linaro。

而不調試符號目標庫

這是常見的嵌入式目標部署之前剝去目標庫，由於調試信息使得它們方式大。

例如，Buildroot默認會這樣做，但您可以用BR2_STRIP_none=y將其禁用。

可以通過運行識別這樣的場景：

info shared 

這都說明是這樣的：

From    To     Syms Read Shared Object Library 
0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*)  target:/lib/ld64-uClibc.so.0 
0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*)  target:/lib/libc.so.0 
(*): Shared library is missing debugging information. 

所以有這兩者說的調試信息缺少庫的星號（*） 。

如果是這樣的話，那麼你必須告訴GDB使用主機上的共享庫之前，他們被剝離。

Buildroot裏面例如讓那麼容易對我們來說，因爲它保持了staging目錄中包含的共享庫，他們被剝奪前，作爲目標相同的相對路徑：

set sysroot buildroot/output/staging/ 

當這個選項集，gdb立即搜索在主機而不是目標庫，並在路徑buildroot/output/staging/ + /lib/libc.so.0發現/lib/libc.so.0：

Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. 
Reading symbols from buildroot/output/staging/lib/libc.so.0...done. 

TODO：我不認爲你可以設置多個sysroot，所以你所有的共享庫必須像目標圖像一樣放置在正確的相對路徑中。

如果檢查不好默認SYSROOT，您將看到：

show sysroot 

得出：

target: 

這意味着gdb搜索在默認情況下對目標根/共享庫。