☰

儘管原始程式碼可用，但 gdb 不會進入函數

tag-icon • tag-icon debugging gdb clang
儘管原始程式碼可用，但 gdb 不會進入函數

我有一個編譯的共享庫，-g -O0包括：

void MyClass::whatever()
{
  ...
  doSomething(myImage, myPoints);
  ...
}

bool MyClass::doSomething(const Image& image, std::vector<cv::Vec2f>& points) const
{ 
  const int32_t foo = 1;
  const float   bar = 0.1f;
  ...
}

現在我正在單步執行whatever()，s但它並沒有單步進入doSomething()，而是超越了它。這不是來源可用性的問題，因為（1）它位於同一個檔案中，並且（2）我可以設定一個斷點doSomething()並毫無問題地單步執行來源。但s似乎相信沒有可用的來源。

如果我set step-mode on，我會得到類似的輸出

0xb5d51148 in myClass::doSomething (this=0xb25e4, image=..., 
points=std::vector of length -91315, capacity 372871920 = {...})
from /path/to/myclass.so

就像沒有可用來源時所得到的。幾次初始化後，n將foo顯示原始程式碼。因此，放在函數開頭的inline參數（類型、發布版本）可能會有一些魔力。opencv是否有可能gdb看到這個東西，認為“奇怪的東西，讓我們在這個函數之後繼續”，並且沒有發現大多數函數確實有可用的源代碼？

（如果重要的話，它是在帶有 Ubuntu 的 ARM 機器上使用 LLVM/clang 3.5 編譯的）

答案1

這很可能是 gcc 優化和後續的問題行號表由...製作矮人 那個地圖

包含程式可執行程式碼的記憶體位址以及與這些位址對應的原始程式碼行

（第 8 頁）

最簡單的解決方案是使用史泰皮當函數達到時

從GDB使用手冊（第 65 頁）

步

繼續運行程序，直到控製到達不同的原始程式碼行，然後停止它並將控制權傳回 gdb。

....

步驟命令僅在原始程式碼行的第一條指令處停止。這可以防止在 switch 語句、for 迴圈等中可能發生的多次停止。換句話說，step 會進入該行內呼叫的任何函數。

此外，只有當函數有行號資訊時，step 指令才會進入該函數。否則它的行為就像下一個命令。這可以避免在 MIPS 計算機上使用 cc -gl 時出現問題。以前，如果存在有關例程的任何調試信息，則單步進入子例程。

相關內容