This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Non-stop multi-threaded debugging


Nick Roberts wrote:
> ... A -thread-select on an > ID of a process followed by an -exec-continue would resume an entire > process, while a -thread-select of a thread's ID followed by a continue > would resume only that thread. This could also be applied to all other > commands that need to operate on a process, such as -thread-list-ids, > -break-insert, etc.

This would change the current behaviour of these commands.  If a new command
is undesirable then perhaps optional parameters could be used:

     -exec-continue [ -p THREAD-ID/PROCESS-ID ]
     -exec-interrupt [ -p THREAD-ID/PROCESS-ID ]

It appears that -break-insert already has such an option for threads.

From Eclipse's point of view it actually doesn't make much difference whether -thread-select or -p option is used to specify the thread.

That said, I would argue that adding the non-stop debugging feature changes the behavior of the entire system, so it could be expected that some commands will behave somewhat differently as they relate to this new feature. Actually, with non-stop debugging feature turned off, and without attaching to multiple processes, these commands would still behave exactly as they do now.

In fact, the original post states:
    - Execution commands like '-exec-continue' and '-exec-step' shall
      resume only the selected thread, without affecting the other
      threads in the process.
So it seems that Jim's proposal would already change the existing behavior of -exec-continue and -exec-step commands.


Also:
At the user interface level:

    - MI shall provide a command to stop all the threads in a given
      process, and a command to resume all stopped threads in a given
      process.
Which to me implies that -exec-continue and -exec-interrupt would act on a single thread, although this is contradicted by the other statement about -exec-interrupt.


Lastly, since my post I thought a little about the CLI aspect in my suggested use of thread IDs. It would probably be a little awkward to use the "thread <id>" command to switch to a different process, or to use it with a process-id to initiate process-wide operations. So for the CLI interface, while I still think it would make sense to use the same ID name-space for processes and threads, it would help to add a couple of new commands:


"process <id>" - To select a new active process where the active thread would be the last active thread in this process. This would be the equivalent of a -thread-select with the last active thread in that process.

"thread all" - To un-select the current thread in order to perform operations on all threads in the process. Equivalent of -thread-select with the ID of the process.

Cheers,
Pawel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]