This is the mail archive of the
mailing list for the GDB project.
Re: MI non-stop interface details
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- Cc: "Pedro Alves" <pedro at codesourcery dot com>, gdb at sourceware dot org, "Pawel Piech" <pawel dot piech at windriver dot com>
- Date: Wed, 30 Apr 2008 11:17:42 +0400
- Subject: Re: MI non-stop interface details
- References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se>
On Tuesday 29 April 2008 22:56:15 Marc Khouzam wrote:
> > > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > > making the case of not passing a --thread parameter semantics
> > > > match? Given the same arguments, if one resumes just one thread,
> > > > the others should too, IMHO.
> > >
> > > Too late. -exec-continue resumes everything. -exec-step, from user
> > > standpoint, resumes one -- most users don't even know that step
> > > can resume all threads.
> > >
> > Oh, I'm talking non-stop mode. It's not too late for that.
> > I played a bit with eclipse/java debugging (which implements non-stop),
> > and noticed it only resumes one thread when one clicks the
> > equivalent of "continue". I have used eclipse/java heavilly in the
> > past, and I never found that unintuitive. I remember
> > looking for a "continue all" button and not finding one, but normally
> > I didn't even thing about it. Resuming one thread was just fine.
> > (I keep thinking that in non-stop mode, the exec commands without
> > --thread are equivalent to the CLI commands in non-stop mode.
> > I keep forgetting to pass --thread to continue& and end up
> > resuming more than I wanted.)
> I'm also leaning towards this: -exec-continue only continuing
> the current thread, a la java.
> Although, also having a 'continue all' may prove useful.
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).