MI commands changing current thread
Simon Marchi
simon.marchi@ericsson.com
Wed Oct 14 15:25:00 GMT 2015
Hi gdb people,
We noticed that MI commands that specify --thread X or --thread-group Y leave
the current thread changed after they execute. Is it a bug or an intentional
feature?
For example:
(gdb) i th
Id Target Id Frame
3 Thread 0x7ffff6ff5700 (LWP 19594) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
2 Thread 0x7ffff77f6700 (LWP 19593) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
* 1 Thread 0x7ffff7fc7740 (LWP 19589) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
(gdb) interpreter-exec mi '-data-evaluate-expression --thread 2 "1+1"'
^done,value="2"
(gdb) i th
Id Target Id Frame
3 Thread 0x7ffff6ff5700 (LWP 19594) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
* 2 Thread 0x7ffff77f6700 (LWP 19593) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
1 Thread 0x7ffff7fc7740 (LWP 19589) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
At first I was convinced it was a bug, as it seems more confusing than useful.
However, I noticed this snippet that decides if the =thread-selected notification
is shown after the MI command executes:
report_change = (ti->num != command->thread);
It will only show the notification if the current thread number (after command
execution) doesn't match the thread specified in the command. In other words,
it seems to say: "if the user specified --thread 2 and the current thread is now
thread 2, don't report the newly selected thread, since the front-end should
know that it sent --thread 2 in the last command, effectively changing the
selected thread".
Any tips?
Simon
More information about the Gdb
mailing list