2014-06-18 54 views
1

gdb控制程序時,它會選擇一個線程作爲「當前線程」。gdb如何選擇「當前線程」?

例如,使用gdb調試核心轉儲文件,腐敗的線程將成爲「當前線程」:

# gdb -q program core_program_0_0_1402630731_27929 
(gdb) bt 
#0 0xfefb2d50 in strlen() from /lib/libc.so.1 
#1 0xff01f4a0 in _ndoprnt() from /lib/libc.so.1 
#2 0xff021cac in vsprintf() from /lib/libc.so.1 
...... 
#9 0xff04aee8 in _lwp_start() from /lib/libc.so.1 

但是,如果程序正在運行,當gdb重視它,它是如何選擇「當前線程」?我做了一個測試,發現它使用主線程作爲「當前線程」。

gdb是否總是選擇主線程作爲「當前線程」?我在gdb manual中進行了搜索,但不幸的是,它沒有任何答案。

有沒有人可以就這個問題發表一些意見?

回答

1

http://sunsite.ualberta.ca/Documentation/Gnu/gdb-5.0/html_node/gdb_24.html

GDB有當前線程設置爲generatesd異常,斷點或目前正在計劃線程。

+0

@ user3737345:當我打開鏈接時,它顯示「404 File not found。」。你能打開它嗎? –

+0

其實我沒有設法在那個頁面上找到'當前安排的'。我甚至沒有找到「預定」。此外,我寫了一個測試,其中第一個線程啓動另一個線程,然後第一個線程進入睡眠狀態(所以它不計劃)。但是,當我使用gdb附加到進程時,當前線程是第一個真正睡眠的線程。 –

2

gdb保持在此變量的當前線程信息:

/* Collected pid, tid, etc. of the debugged inferior. When there's 
    no inferior, ptid_get_pid (inferior_ptid) will be 0. */ 

extern ptid_t inferior_ptid; 

我覺得怎麼gdb連接到一個進程後選擇當前線程它可能是依賴於平臺。以Linux上的gdb爲例。在Linux上,進程的PID等於其主線程的PID。所以gdb使用進程的PID要附加到作爲進程的當前線程的ID:

這是gdb代碼在當前線程ID設置:

static void 
linux_nat_attach (struct target_ops *ops, char *args, int from_tty) 
{ 
    struct lwp_info *lp; 
    int status; 
    ptid_t ptid; 
    volatile struct gdb_exception ex; 

    /* Make sure we report all signals during attach. */ 
    linux_nat_pass_signals (0, NULL); 

    TRY_CATCH (ex, RETURN_MASK_ERROR) 
    { 
     linux_ops->to_attach (ops, args, from_tty); 
    } 

    /* some code is skipped */ 

    /* The ptrace base target adds the main thread with (pid,0,0) 
    format. Decorate it with lwp info. */ 
    ptid = BUILD_LWP (GET_PID (inferior_ptid), GET_PID (inferior_ptid)); 
    thread_change_ptid (inferior_ptid, ptid); 

所以使用pid作爲當前線程的LWP的值的過程。這是當前線程ID設置的回溯:

Hardware watchpoint 1: inferior_ptid 

Old value = {pid = 11386, lwp = 0, tid = 0} 
New value = {pid = 11386, lwp = 11386, tid = 0} 
0x000000000057ba69 in infrun_thread_ptid_changed (old_ptid=..., new_ptid=...) at infrun.c:1592 
1592  inferior_ptid = new_ptid; 
(gdb) bt 
#0 0x000000000057ba69 in infrun_thread_ptid_changed (old_ptid=..., new_ptid=...) at infrun.c:1592 
#1 0x00000000005c87ca in observer_thread_ptid_changed_notification_stub (data=0x0, args_data=0x0) at observer.inc:728 
#2 0x00000000005c8595 in generic_observer_notify (subject=<optimized out>, args=0x7fffffffdcc0) at observer.c:167 
#3 0x00000000005c8c37 in observer_notify_thread_ptid_changed (old_ptid=..., new_ptid=...) at observer.inc:753 
#4 0x000000000048b81b in linux_nat_attach (ops=0xb95220, args=0x7fffffffe3b3 "11386", from_tty=1) at linux-nat.c:1635 
#5 0x00000000005b7879 in target_attach (args=0x7fffffffe3b3 "11386", from_tty=1) at target.c:3798 
#6 0x000000000057a587 in attach_command (args=0x7fffffffe3b3 "11386", from_tty=1) at infcmd.c:2578 
#7 0x00000000005919e7 in catch_command_errors (command=0x57a4f0 <attach_command>, arg=0x7fffffffe3b3 "11386", from_tty=1, mask=<optimized out>) at exceptions.c:573 
#8 0x00000000005940d8 in captured_main (data=<optimized out>) at main.c:963 
#9 0x0000000000591a94 in catch_errors (func=0x593330 <captured_main>, func_args=0x7fffffffdfd0, errstring=0x759429 "", mask=6) at exceptions.c:546 
#10 0x0000000000593094 in gdb_main (args=<optimized out>) at main.c:1050 
#11 0x0000000000457a76 in main (argc=<optimized out>, argv=0x0) at gdb.c:34