GDB多線程調試的基本命令。

info threads
顯示當前可調試的所有線程，每個線程會有一個GDB為其分配的ID，后面操作線程的時候會用到這個ID。
前面有*的是當前調試的線程。

thread ID
切換當前調試的線程為指定ID的線程。

break thread_test.c:123 thread all
在所有線程中相應的行上設置斷點

thread apply ID1 ID2 command
讓一個或者多個線程執行GDB命令command。

thread apply all command
讓所有被調試線程執行GDB命令command。

set scheduler-locking off|on|step
估計是實際使用過多線程調試的人都可以發現，在使用step或者continue命令調試當前被調試線程的時候，其他線程也是同時執行的，怎么只讓被調試程序執行呢？通過這個命令就可以實現這個需求。
off 不鎖定任何線程，也就是所有線程都執行，這是默認值。
on 只有當前被調試程序會執行。
step 在單步的時候，除了next過一個函數的情況(熟悉情況的人可能知道，這其實是一個設置斷點然后continue的行為)以外，只有當前線程會執行。

在介紹完基本的多線程調試命令后，大概介紹一下GDB多線程調試的實現思路。

比較主要的代碼是thread.c，前面介紹的幾個命令等都是在其中實現。
thread_list這個表存儲了當前可調試的所有線程的信息。
函數add_thread_silent或者add_thread(不同版本GDB不同)用來向thread_list列表增加一個線程的信息。
函數delete_thread用來向thread_list列表刪除一個線程的信息。
上面提到的這2個函數會被有線程支持的target調用，用來增加和刪除線程，不同的OS對線程的實現差異很大，這么實現比較好的保證了GDB多線程調試支持的擴展性。
函數info_threads_command是被命令info threads調用的，就是顯示thread_list列表的信息。
函數thread_command是被命令thread調用，切換當前線程最終調用的函數是switch_to_thread，這個函數會先將當前調試線程變量inferior_ptid，然后對寄存器和frame緩沖進行刷新。
函數thread_apply_command被命令thread apply調用，這個函數的實際實現其實很簡單，就是先切換當前線為指定線程，然后調用函數execute_command調用指定函數。

比較特別的是set scheduler-locking沒有實現在thread.c中，而是實現在控制被調試程序執行的文件infrun.c中。
對 其的設置會保存到變量scheduler_mode中，而實際使用這個變量的函數只有用來令被調試程序執行的函數resume。在默認情況下， 傳遞給target_resume的變量是resume_ptid，默認情況下其的值為RESUME_ALL，也就是告訴target程序執行的時候所有 被調試線程都要被執行。而當scheduler_mode設置為只讓當前線程執行的時候，resume_ptid將被設置為inferior_ptid， 這就告訴target只有inferior_ptid的線程會被執行。

最后特別介紹一下Linux下多線程的支持，基本的調試功能在linux-nat.c中，這里有對Linux輕量級別進程本地調試的支持。但是其 在調試多線程程序的時候，還需要對pthread調試的支持，這個功能實現在linux-thread-db.c中。對pthread的調試要通過調用 libthread_db庫來支持。
這里有一個單獨的target"multi-thread"，這個target有2點很特別:
第 一，一般target的裝載是在調用相關to_open函數的時候調用push_target進行裝載。而這個target則不同，在其初始化 的時候，就注冊了函數thread_db_new_objfile到庫文件attach事件中。這樣當GDB為調試程序的動態加載庫時候attach庫文 件的時候，就會調用這個函數thread_db_new_objfile。這樣當GDB裝載libpthread庫的時候，最終會裝載 target"multi-thread"。
第二，這個target并沒有像大部分target那樣自己實現了全部調試功能，其配合linux-nat.c的代碼的功能，這里有一個target多層結構的設計，要介紹的比較多，就不詳細介紹了。

最后介紹一下我最近遇見的一個多線程調試和解決。

基本問題是在一個Linux環境中，調試多線程程序不正常，info threads看不到多線程的信息。
我先用命令 maintenance print target-stack看了一下target的裝載情況，發現target"multi-thread"沒有被裝載，用GDB對GDB進行調試，發現在 函數check_for_thread_db在調用libthread_db中的函數td_ta_new的時候，返回了TD_NOLIBTHREAD，所 以沒有裝載target"multi-thread"。
在時候我就懷疑是不是libpthread有問題，于是檢查了一下發現了問題，這個環 境中的libpthread是被strip過的，我想可能 就是以為這個影響了td_ta_new對libpthread符號信息的獲取。當我換了一個沒有strip過的libpthread的時候，問題果然解決 了。
最終我的解決辦法是拷貝了一個.debug版本的libpthread到lib目錄中，問題解決了。  多線程如果dump，多為段錯誤，一般都涉及內存非法讀寫。可以這樣處理，使用下面的命令打開系統開關，讓其可以在死掉的時候生成core文件。  
ulimit -c unlimited
這樣的話死掉的時候就可以在當前目錄看到core.pid(pid為進程號)的文件。接著使用gdb:
gdb ./bin ./core.pid
進去后，使用bt查看死掉時棧的情況，在使用frame命令。

還有就是里面某個線程停住，也沒死，這種情況一般就是死鎖或者涉及消息接受的超時問題(聽人說的，沒有遇到過)。遇到這種情況，可以使用：
gcore pid （調試進程的pid號）
手動生成core文件，在使用pstack(linux下好像不好使)查看堆棧的情況。如果都看不出來，就仔細查看代碼，看看是不是在if，return，break，continue這種語句操作是忘記解鎖，還有嵌套鎖的問題，都需要分析清楚了。

from:

http://blog.chinaunix.net/u3/91335/showart.php?id=2249238