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