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:
On Thursday 29 November 2007 20:36:18 Pawel Piech wrote:
Vladimir Prus wrote:
On Thursday 29 November 2007 19:39:18 Pawel Piech wrote:

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.
Ok, we have those choices:

1. Make -exec-continue work on all threads, until -thread-select is used.
2. Make -exec-continue work on one thread, and add another command
to operate on all threads.
3. Make -exec-continue still operate on all threads, unless
and explicit option to make it operate on a thread is given.

You've indicated that (1) and (3) are about the same in complexity for you --
am I right?
This is correct.
I personally prefer (3), since it does not implicitly changes
the meaning of existing commands.

Surely, non-stop mode does require some changes in frontend, but the
fewer changes are, the better, IMO.

- Volodya
In that case I'll try to convince you otherwise :-)

-exec-continue is not the only command that would need to be modified. -exec-interrupt, would all need to take the -p parameter, and in order to implement multi-process debugging, many of the commands that currently operate on a global context (too many to try to list) would all require an additional parameter to specify which process they are to act on. There seems to be a well established paradigm in the MI (and CLI) protocol, where special commands: -thread-select and -stack-frame-select change the state of the protocol so that commands following these operate on the context selected by these commands.

There are different opinions about those commands ;-) For example, I believe that stateless protocol would be much easier.

I completely agree with you, for a "machine interface" a stateless protocol would be much easier to use. But GDB/MI is what it is and at this point trying to make it stateless would probably be counter productive.
My main point is to extend the functionality of these state-changing commands in order to add the ability to select an active context, and to select a context which will allow commands to operate on all the threads of a process.

IMO, the question of whether -exec-continue takes a -p argument is a rather minor one. But for sake of consistency with other -exec-* commands I think it would be a mistake to add this parameter. That's because the stepping commands already do operate on the currently selected thread. While all the threads are resumed when stepping, execution does not stop until the next line of code is reached by the thread that was selected. With non-stop debugging, stepping commands will continue to operate on the selected thread with the difference that other suspended threads will remain suspended.

Interesting. Presently, in CLI gdb set 'scheduler mode' that controls if step resumes all thread, or not. MI does not have a counterpart of that. Maybe, we should start by changing -exec-step to accept a thread parameter, too, which would mean "step only this thread, keep others suspended". Then, -exec-continue taking thread parameter will be quite consistent with -exec-step. I would say such change to -exec-step will be valuable in itself.

- Volodya
I'm rather confused here. I thought that the point of non-stop multi-threaded debugging was to allow for this behavior. Is "scheduler mode" some kind of partial implementation? Either way though, I have no opinion whether it would be useful for the command line user to be able to specify the scheduling mode as an option to individual commands, but in an IDE such behavior would most likely be controlled with a toggle button, so a mode switch command would be sufficient. If -exec-step would take a -p parameter to determine whether to resume all threads, then -exec-step without -p would still operate on the selected thread, in that it would suspend the process only when the selected thread reached the next line. IHMO, this would only add to the confusion.

Cheers,
Pawel


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