MI commands with --thread (--frame?) do not preserve user selected thread / frame

Jan Vrany jan.vrany@fit.cvut.cz
Wed Jun 19 10:53:00 GMT 2019


Hi, 

I was debugging a multithreaded program and realized that using --thread option to
verious MI command silently changes user selected thread - here's an example using
separate UI and CLI chahhel (tested on commit 6f5601c4d0)

Step 1: CLI info thread + info frame
====================================
--- CLI channel 
(gdb) info thread
  Id   Target Id                                           Frame 
* 1    Thread 0x7ffff7c30740 (LWP 10185) "user-selected-c" main () at /home/jv/Projects/gdb/origin_master/gdb/testsuite/gdb.mi/user-selected-context-sync.c
:60
  2    Thread 0x7ffff7c2f700 (LWP 10186) "user-selected-c" child_sub_function () at /home/jv/Projects/gdb/origin_master/gdb/testsuite/gdb.mi/user-selected-context-sync.c
:30
  3    Thread 0x7ffff742e700 (LWP 10187) "user-selected-c" futex_wait (private=0, expected=0, futex_word=0x555555558084 <barrier+4>) at ../sysdeps/unix/sysv/linux/futex-internal.h
:61
(gdb) info frame
Stack level 0, frame at 0x7fffffffdee0:
 rip = 0x555555555207 in main (/home/jv/Projects/gdb/origin_master/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b
 source language c.
 Arglist at 0x7fffffffded0, args: 
 Locals at 0x7fffffffded0, Previous frame's sp is 0x7fffffffdee0
 Saved registers:
  rbp at 0x7fffffffded0, rip at 0x7fffffffded8

--- MI channel 
 <no input no output>



Step 2: MI -stack-info-depth --thread 3
=======================================
-- CLI channel
 <no input no output>

--- MI channel
(gdb) 
-stack-info-depth --thread 3
^done,depth="6"
(gdb)




Step 3:  CLI info thread + info frame (same as in Step 1)
=========================================================
-- CLI channel
(gdb) info thread
  Id   Target Id                                           Frame 
  1    Thread 0x7ffff7c30740 (LWP 10185) "user-selected-c" main () at /home/jv/Projects/gdb/origin_master/gdb/testsuite/gdb.mi/user-selected-context-sync.c
:60
  2    Thread 0x7ffff7c2f700 (LWP 10186) "user-selected-c" child_sub_function () at /home/jv/Projects/gdb/origin_master/gdb/testsuite/gdb.mi/user-selected-context-sync.c
:30
* 3    Thread 0x7ffff742e700 (LWP 10187) "user-selected-c" futex_wait (private=0, expected=0, futex_word=0x555555558084 <barrier+4>) at ../sysdeps/unix/sysv/linux/futex-internal.h
:61
(gdb) info frame
Stack level 0, frame at 0x7ffff742dee0:
 rip = 0x7ffff7f8612e in futex_wait (../sysdeps/unix/sysv/linux/futex-internal.h:61); saved rip = 0x555555555183
 inlined into frame 1
 source language c.
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp in rsp
(gdb)   

--- MI channel 
 <no input no output>



As you can see, there was no `frame`, `thread`, `-select-frame` or `-thread-select` command between
first and second info thread / frame commands on CLI, yet the selected thread / frame changed (silently).

Is this intended behavior? If so what's the rationale?

Thanks! 

Jan



More information about the Gdb mailing list