gdb：如何了解哪個共享庫加載了有問題的共享庫

Question

我需要獲取應用程序在運行時使用的共享庫列表。 其中大部分可以通過ldd列出，但有些只能通過gdb -p <pid>和運行 gdb 命令info sharedlib 。

如果我能以某種方式學習，那真的很有幫助：對於一個選定的庫（在列表中，output by info sharedlib ），哪個庫（在同一個列表中）導致加載它。 有什么方法可以在gdb或者其他途徑學習嗎？ 因為有時，我會在列表中看到一個已加載的庫，但無法理解為什么它在那里以及哪個（可能之前已加載到內存中）庫加載了它。

更新：

我附上了 gdb 的屏幕截圖，顯示了我需要的信息。 我在dlopen上使用了斷點，正如評論和答案中所建議的那樣。 命令x/s $rdi打印出dlopen的第一個參數，如 Linux System V ABI，即它打印庫的名稱，我想知道是誰加載了它 ( libdebuginfod.so.1 )。 我把它放在這里只是為了那些好奇的人。 在我的例子中，可以看出， libdebuginfod.so.1是由libdw.so.1加載的（如bt命令所示）。

Answer 1

有什么方法可以在gdb或者其他途徑學習嗎？

有幾種方法。

您可以使用env LD_DEBUG=files /path/to/exe運行該程序。

這將產生類似於以下內容的 output：

 LD_DEBUG=files /bin/date
     76042:
     76042:     file=libc.so.6 [0];  needed by /bin/date [0]

這是您最關心的部分所需要的。

您還可以使用 GDB 並使用set set stop-on-solib-events 1 。 這將產生類似於以下內容的 output：

Stopped due to shared library event:
  Inferior loaded /lib/x86_64-linux-gnu/libc.so.6

此時，您可以執行where命令並觀察哪個dlopen()調用導致加載新庫。

您還可以在dlopen()上設置斷點並執行相同操作。

如果您的可執行文件重復dlopen()同一個庫，則stop-on-solib-events可能會更好——當您再次 dlopen( dlopen()同一個庫時，庫集不會改變，當您不這樣做時，您將停止小心停下來。 設置stop-on-solib-events可以避免這種不必要的停止。