On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
In DSF-GDB there _is_ a central place where commands are sent, this is
where the protocol state is adjusted using -thread-select. However, the
--thread option is being added to many but not all commands, so the same
mechanism that adds the -thread-select could not be reused to add
--thread option. Instead each command which accepts --thread that would
need to be adjusted to use the --thread, but only when in non-stop
debugging mode.
This is not actually. The plan is for eery command will accept --thread.
Those that don't have any use of it will ignore it. The only command,
at the moment, for which the meaning of --thread is not yet clear, and for
which the frontend might have to have custom decision logic, is --exec-continue.
- Volodya
That's helpful. Unfortunately UI clients that want to have a wide user base still
need to worry about old GDB versions which do not support -thread, and that was my
first point in this thread. As I've seen on this mailing list there are users out
there still on GDB 5.x. I expect it will take several
years before support for GDB 6.8 and prior is not so important.
And where's the issue? On startup, issue -list-features. If you get error, this is old
GDB. If the output of -list-features does not include "thread-option", this version of
GDB does not support --thread (and don't not support non-stop, either). Then, you
can make appropriate runtime decisions. It seems better to me to make such global
decision right after starting GDB, rather than guessing things from output of *stopped,
and other indirect mechanisms.
[Note that "thread-option" is not yet produced by -list-features, because the support
for --thread is not yet in FSF tree]
- Volodya