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


Vladimir Prus wrote:
Pawel Piech wrote:

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.

Given the choice between:


1. Changing the behaviour of the existing command, and adding new one
that behaves like existing one, and

2. Adding new command

I think adding new command (or option to existing command), is a smaller change.
So yes, -exec-continue -t <xxx> might be a better choice.

- Volodya
I don't believe that I suggested adding any new command. Instead, I suggested only changing the behavior of some of the existing commands to use the currently selected thread. It was Jim's proposal that included adding new commands. My point was that instead of adding new commands it would be cleaner to extend the functionality of -thread-select in order to select a process context, i.e. a context that includes all threads. This way existing commands, which currently can only operate on a global context, could now operate on a process or a thread context.

Cheers,
Pawel



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