uboot有兩個階段，重定位之前和重定位之後，這兩個階段的符號表是不一樣的，因此需關注是除錯重定位之前的uboot還是重定位之後的uboot(以riscv版uboot為例)
1. 除錯重定位之前的uboot
1.1 使用qemu啟動uboot，並進入除錯模式
$ qemu-system-riscv64 -nographic -machine virt -m 512 -kernel /build/platform/qemu/virt/firmware/fw_jump.elf -device loader,file=/u-boot.bin -s -s
1.2 除錯重定位之前的uboot
$ riscv64-unknown-linux-gnu-gdb /u-boot
(gdb) target remote :1234
(gdb) b board_init_f
(gdb) c
2. 除錯重定位之後的uboot
2.1 使用qemu啟動uboot，並進入除錯模式（同1.1）
2.2 除錯重定位之前的uboot
$ riscv64-unknown-elf-gdb(riscv64-unknown-linux-gnu-gdb) /u-boot
(gdb) target remote :1234
//獲取重定位之後uboot在記憶體中的位址
(gdb) b relocate_code (relocate_code函式的引數指定了重定位之後的uboot位址)
(gdb) c
(gdb) info register a2
0x8ff64000
(gdb) b call_board_init_r
(gdb) symbol-file (delete old symbols)
discard symbol table `~/u-boot` (y or n) y
// 加載重定位之後的符號表
(gdb) add-symbol-file /u-boot 0x8ff64000
add symbol table file from "~/u-boot" at
.text_addr = 0x8ff64000
(y or n) y
(gdb) b board_init_r
(gdb) c
Linux上如何測試 執行python指令碼
有兩種方式 1 直接使用python x.py執行。其中python可以寫成python的絕對路徑。使用which python進行查詢。2 在檔案的頭部 第一行 寫上 usr bin python2.7，這個地方使用python的絕對路徑，就是上面用which python查詢來的結果。然後在外面...
用gdb除錯執行中的程式
今天一早到了公司，策劃就和我說，前幾天出過問題的那台伺服器，玩家又登陸不上遊戲了。上去一看，又是cpu使用100 這問題最近經常出現，又不好查，就乾脆讓運維先別重啟了，直接上線除錯。一開始以為是lua指令碼的死迴圈，後來才發現原來是底層的定時器問題。查了一整個上午，學到了一些gdb的東西，這裡記錄一...
C 將程序執行在指定的CPU上
方法 setprocessaffinitymask handle,dword 其中，第乙個引數為程序控制代碼。如果要知道當前執行緒的控制代碼，可以通過函式 getcurrentthread 得到。否則，在建立多執行緒的時候，也同樣可以得到建立的執行緒的控制代碼。第二個引數為mask，可取值為0 2 ...