RE: MI commands changing current thread

Hi Simon,

Documentation says that you should rely on the selected thread, best method is always to pass the argument --thread.

Here is the part of the documentation:

' In particular, if the frontend sends several commands to gdb, and one of the commands changes the selected thread, then the behaviour of subsequent commands will change. So, a frontend should either wait for response from such problematic commands, or explicitly add -thread-select for all subsequent commands.
No frontend is known to do this exactly right, so it is suggested to just always pass the ‘--thread’ and ‘--frame’ options.'

Hope to have helped,
Regards,
-Fred


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Simon Marchi
Sent: Wednesday, October 14, 2015 5:25 PM
To: [email protected]
Subject: MI commands changing current thread

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
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928