gdbback-trace沒有顯示linux-5.10.0或linux-5.10.122的所有函式呼叫堆疊，為什么？

我希望答案包含如何使用 gdb 查看 linux-5.10.0 或 5.10.122 版本的完整堆疊。在以前的 linux 版本中沒有問題。

這里發生了非常奇怪的事情。我在 gdb 中看不到使用“bt”命令的完整堆疊跟蹤。所以我嘗試了新的 linux-5.10.122 源和 qemu-6.2.0 源，它也在發生！（但對于帶有 defconfig 的 linux-5.4.21 和 qemu 5.1.0 或 6.2.0 不會發生這種情況）

如果有人可以檢查這種情況是否發生在其他人或只是我身上，我將不勝感激。

1. 從https://www.kernel.org/下載 linux-5.1.122 壓縮包
2. 解壓縮并設定環境變數 ARCH=arm64, CROSS_COMPILE=aarch64-none-elf- ，執行“make defconfig”和“make -j nprocImage”
3. 從https://www.qemu.org/下載 qemu-6.2.0
4. 解壓縮并執行“mkdir build”“cd build”“../configure --target-list=aarch64-softmmu --enable-debug”
5. 運行 qemu 并等待除錯器附加。
   qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic-version=max,secure=off,virtualization=true -cpu max -kernel linux-5.10.112/arch/arm64/boot /Image -m 2G -nographic -netdev user,id=vnet,hostfwd=:127.0.0.1:0-:22,tftp=/srv/tftp -device virtio-net-pci,netdev=vnet -machine iommu=smmuv3 - -追加“root=/dev/ram init=/init nokaslr earlycon ip=dhcp hugepages=16”-s -S
6. 運行除錯器，執行“aarch64-none-elf-gdb linux-6.10.112/vmlinux -x gdb_script”（gdb_script 內容：目標遠程：1234 布局 src b start_kernel b __driver_attach）

現在，在 gdb 中，當您按兩次“c”時，它將在第一個 __driver_attach 處停止。（第一個停在 start_kernel）。當您在 __attach_driver 時，輸入“bt”。看看您是否看到完整的函式堆疊跟蹤。
這就是我所看到的。

(gdb) bt
#0  __driver_attach (dev=0xffff000002582810, data=0xffff800011dc2358 <dummy_regulator_driver 40>)
    at drivers/base/dd.c:1060
#1  0xffff8000107a3ed0 in bus_for_each_dev (bus=<optimized out>, start=<optimized out>,
    data=0xffff800011dc2358 <dummy_regulator_driver 40>, fn=0xffff8000107a6f60 <__driver_attach>)
    at drivers/base/bus.c:305
#2  0xd6d78000107a5c58 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

我曾經看到超過 20 個堆疊幀，但奇怪的是我只看到了兩個。我仍然可以看到我過去使用的許多 linux-5.4.21 堆疊。
誰能檢查這是否也發生在其他人身上？即使我看不到整個堆疊幀，我認為如果我在 linux 構建中添加 BLK_DEV_RAM 并設定 initramfs.cpio.gz，內核將正常啟動到 shell 提示符。所以 linux 運行正常，但只有 gdb 不能顯示堆疊級別。

我的作業系統：ubuntu-20.04 5.13.0-35-generic

$ aarch64-none-elf-gdb --version
GNU gdb (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16)) 10.1.90.20201028-git 著作權所有 (C) 2020 Free Software Foundation, Inc. 許可 GPLv3 ： GNU GPL 版本 3 或更高版本http://gnu.org/licenses/gpl.html 這是免費軟體：您可以自由更改和重新分發它。在法律允許的范圍內，不提供任何保證。看起來隨著內核版本的增加，在某些時候 gdb 'bt' 命令有問題？

添加

我發現CONFIG_DEBUG_FRAME_POINTER、CONFIG_DEBUG_INFO已經默認設定了。我嘗試添加 CONFIG_DEBUG_KERNEL、CONFIG_KGDB、CONFIG_GDB_SCRIPTS、CONFIG_STACKTRACE 都無濟于事。我需要為 arm64 qemu virt 機器做這件事。

ADD2 01:10 2022 年 4 月 26 日 UTC

我在 __driver_attach 的另一個斷點案例中發現，

(gdb) bt
#0  __driver_attach (dev=dev@entry=0xffff0000401d1810, data=data@entry=0xffff800011bbbbb8 <mxc_gpio_driver 40>) at drivers/base/dd.c:1046
#1  0xffff8000107684f8 in bus_for_each_dev (bus=0xffff800011cba910 <platform_bus_type>, start=0x0, data=0xffff800011bbbbb8 <mxc_gpio_driver 40>, fn=0xffff80001076b860 <__driver_attach>) at drivers/base/bus.c:307
#2  0xb8cd80001076a594 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) x/5g $sp
0xffff800011dcbcc0: 0xffff800011dcbd20  0xb8cd80001076a594
0xffff800011dcbcd0: 0xffff80001076b860  0xffff800011bbbbb8
0xffff800011dcbce0: 0x0000000000000000

因為就在 pc 到達函式 __driver_attach 之后，sp 仍然沒有從之前的函式 (bus_for_each_dev) 更新。$sp 的前兩個值應該是前一個函式的 fp 和 lr（參見了解 aarch64 匯編函式呼叫，堆疊操作arm64 如何在新堆疊幀進入時將前一個函式的 fp 和 lr 存盤在新堆疊幀的底部一個函式）。lr（鏈接暫存器，在這個 bus_for_each_dev 函式之后回傳的地址）是 0xb8cd80001076a594，這很奇怪（不是內核地址）。以下 3 個值是 bus_for_each_dev 的函式引數，它們看起來是正確的。

添加（08:20 27/04/2022 UTC）

我試圖打破 driver_attach。它呼叫 bus_for_each_dev 和 bus_for_each_dev 呼叫 __driver_attach。當我輸入 bus_for_each_dev 時，我檢查了匯編代碼。它將 x29 和 x30 放置在 [sp, #-80] 處！( stp x29, x30, [sp, #-80]!) 所以我檢查了 x29(fp) 和 x30(lr) 的值。它們分別是 0xffff800011efbd20 和 0xffff8000107a52f8。這些值被放置在 bus_for_each_dev 堆疊幀的底部。現在在 bus_for_each_dev 函式中，我輸入 __driver_attach。此時我檢查了$sp中的兩個值（sp值仍然是bus_for_each_dev的值）。它們是 0xffff800011efbd20（正確）和 0xc9a48000107a52f8（錯誤！）。為什么高16位改變了？
我很快發現當 x29、x30 被寫入新的堆疊底部時，x30 的高 16 位首先寫入了錯誤的值。因此，如果我將這 16 位修復為正確的值（通常為 0xffff，因為最高內核地址位是 0xffff），bt 輸出顯示更多。x30 修復越多，我可以看到的堆疊幀就越多。我已經向 bugs.linaro.org 提交了一個錯誤，以便專家可以檢查這一點。

uj5u.com熱心網友回復：

我剛剛發現通過在構建linux時在armv8.3中關閉CONFIG_ARM64_PTR_AUTH，我可以避免這個問題。（我注意到函式匯編代碼開頭的指令“pacia”）（我詢問了 kernelnewbies 和 qemu-discuss 電子郵件串列，但專家不經常回復..）希望這對以后的人有所幫助。

標籤：调试 linux内核 数据库 linux-设备驱动程序

上一篇：在C#中創建托管可視化器的最簡單方法是什么？

下一篇：如果提示為空，如何停止js腳本