multithreading - gdb如何选择 “current thread”？

Question

当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，但是不幸的是，没有答案。

有人可以对此问题发表评论吗？

Answer 1

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的backtrace:

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