This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command.
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, gdb-patches at sourceware dot org
- Date: Tue, 12 Aug 2008 10:09:11 +0400
- Subject: Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command.
- References: <200806282054.03092.vladimir@codesourcery.com> <20080805182735.GA7381@caradoc.them.org> <200808052008.47713.pedro@codesourcery.com>
On Tuesday 05 August 2008 23:08:46 Pedro Alves wrote:
> A Tuesday 05 August 2008 19:27:35, Daniel Jacobowitz wrote:
>
> > I can't follow all the possibilities being juggled in this
> > conversation. But why not just set non-stop in advance, regardless of
> > the target, and then issue an error at run / target remote / wherever
> > if non-stop is not available?
>
> Yes, that's what I've been proposing/saying we must do. Clearly, I
> can't express myself that well.
>
> > > We leaves some slack to add new modes like this, which would
> > > combine (1) and (2):
> > >
> > > set prefered-execution-mode
> > > "all-stop"
> > > prefer all-stop, but if the target doesn't support it, fine.
> > > "non-stop"
> > > prefer non-stop, but if the target doesn't support it, fine.
> > > "force-all-stop"
> > > require all-stop, fail if the target refuses it.
> > > "force-non-stop"
> > > require all-stop, fail if the target refuses it.
> >
> > Please don't, the user should know what they get.
>
> Ok, then we're back to what we have currently. I only proposed
> that, because Vladimir didn't like the exception/error that is
> currenly thrown. (In the unsubmited remote target; linux
> doesn't do it yet). I'll leave it to Vladimir to justify
> not having an error and falling back to all-stop/non-stop, if he
> still wants it.
My motivation was that the most intuitive model is that of
immediate application of non-stop flag, with error produced
immediately. This is hard to implement.
Next most intuitive model is "I prefer non-stop mode", which is
what I propose.
The model where 'non-stop' variable is a hard request,
but the error is delayed seems fairly unconventional to me.
- Volodya