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] |
On Thursday 01 May 2008 22:06:03 Pawel Piech wrote:As I mentioned before, having lots of "if (new)... else (old)..." makes the code hard to maintain after a while. I think Nick got it right, maintaining backward compatibility is more work for the server, dealing with incompatibilities is more work for the client. Right now what you're saying is: "what's the big deal, just do a little more work". Keep in mind though, there is one server, and many clients.
Vladimir Prus wrote:
On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:Adoption of new versions of GDB is gradual, so for clients support for old versions of GDB is very important.
Vladimir Prus wrote:Why do you have such a goal?
First of all I really appreciate your effort to maintain backward compatibility. I know that it can seriously complicate the effort to add new features but I believe this effort pays off in quicker and more reliable adoption by the users (IDEs). However, there are two kinds of backward compatibility goals to consider:Again -- exec-continue resuming just one thread will be a change in behaviour. We can take two approaches:
1. The MI interface we've discussed for non-stop is essentially MI3 (and will be used both in all-stop and non-stop mode). We're in position to change anything we like, and are not bound by backward compatibility, or anything.
2. The MI interface for non-stop is MI2 + minimal set of changes. I think that Pawel's opposition to the --thread idea indicates that he prefers this approach. Then, we rather not change the behaviour of existing commands.
There are not many high-level warts in MI2/non-stop/async, so I'm willing to go with (2).
- Volodya
1) Allowing old GDB clients to use the new, extended protocol.
2) Allow clients that use the extended protocol to easily work with old protocol versions. And by "easily", I mean that the client should be able to not have "if(non-stop) { use command a } else { use command b}" kind of logic scattered throughout its implementation.
The "else" branch of your conditional handles old version of GDB, no?
This leaves out an important piece of information: the triggering thread, which is used by the IDE to decide which thread should get the focus. You may not see a use case for it now, but sooner or later you will add an option to the breakpoint to stop all threads in non-stop mode and you'll want to tell the client which thread hit the breakpoint.Currently, both *running and *stopped have "thread-id" field.But your proposal doesn't add any fields to the events indicating whether the stopped event stops a single thread or the whole process.
If the thread-id field has a value of "all", then all threads are stopped,
but it's just a shortcut for a number of *stopped, one per each thread.
Can you think of a scenario in a client which would break? Would KDevelop break? Maybe implementers of other client can speak up on this.I'll probably start designing multi-process extensions for MI this week,I see no reason to create a separate name space and in fact adding another name space just requires more logic to maintain it. thread-id is just a handle that is obtained through well-documented commands, the MI clients are not likely to get confused by the fact that containers and threads are in the same namespace. Additionally, if GDB was ever to support more hierarchical systems: such as target->core->processes->threads, it will have to keep revising the protocol (in incompatibility inducing ways) to keep up. But I guess you'd have to believe that this is a real issue first.
and will look into these suggestions. Why are you trying to use same
namespace for process ids and thread ids?
- Volodya
I think the MI commands to query the hierarchy of "containers" will be fairly
agnostic of the actual meaning of each containers (just like variable objects
allow to describe arbitrary structure). That said, I'm not 100% that
making the namespace of containers and namespace of thread IDs is not going
to upset existing frontends.
- Volodya
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |