[doc] NEWS: QCatchSyscalls: simplify

  On Sat, 09 Jan 2016 04:09:14 +0100, Josh Stone wrote:
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -120,6 +120,21 @@ N stop reply
>    threads are stopped).  The remote stub reports support for this stop
>    reply to GDB's qSupported query.
>  
> +QCatchSyscalls:1 [;SYSNO]...
> +QCatchSyscalls:0
> +  Enable ("QCatchSyscalls:1") or disable ("QCatchSyscalls:0")
> +  catching syscalls from the inferior process.
> +
> +syscall_entry stop reason
> +  Indicates that a syscall was just called.
> +
> +syscall_return stop reason
> +  Indicates that a syscall just returned.
> +
> +QCatchSyscalls:1 in qSupported
> +  The qSupported packet may now include QCatchSyscalls:1 in the reply
> +  to indicate support for catching syscalls.
> +
>  * Extended-remote exec events
>  
>    ** GDB now has support for exec events on extended-remote Linux targets.

I find this format non-standard/confusing.  OK to check-in this update?


Thanks,
Jan
gdb/ChangeLog
2016-05-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* NEWS (QCatchSyscalls): Remove the parameter.  Include ...
	(QCatchSyscalls:1 in qSupported) ... this separate entry which got
	deleted.
  

> Date: Sun, 29 May 2016 18:47:45 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org, philippe.waroquiers@skynet.be,
>         sergiodj@redhat.com, palves@redhat.com, eliz@gnu.org, xdje42@gmail.com,
>         scox@redhat.com, Josh Stone <jistone@redhat.com>
> 
> On Sat, 09 Jan 2016 04:09:14 +0100, Josh Stone wrote:
> > --- a/gdb/NEWS
> > +++ b/gdb/NEWS
> > @@ -120,6 +120,21 @@ N stop reply
> >    threads are stopped).  The remote stub reports support for this stop
> >    reply to GDB's qSupported query.
> >  
> > +QCatchSyscalls:1 [;SYSNO]...
> > +QCatchSyscalls:0
> > +  Enable ("QCatchSyscalls:1") or disable ("QCatchSyscalls:0")
> > +  catching syscalls from the inferior process.
> > +
> > +syscall_entry stop reason
> > +  Indicates that a syscall was just called.
> > +
> > +syscall_return stop reason
> > +  Indicates that a syscall just returned.
> > +
> > +QCatchSyscalls:1 in qSupported
> > +  The qSupported packet may now include QCatchSyscalls:1 in the reply
> > +  to indicate support for catching syscalls.
> > +
> >  * Extended-remote exec events
> >  
> >    ** GDB now has support for exec events on extended-remote Linux targets.
> 
> I find this format non-standard/confusing.  OK to check-in this update?

Is it really that bad?  I generally tend to let people say things in
their own words, as long as it's readable.  But if you insist...
  

On Sun, 29 May 2016 19:29:19 +0200, Eli Zaretskii wrote:
> Is it really that bad?  I generally tend to let people say things in
> their own words, as long as it's readable.  But if you insist...

That :1 and :0 was confusing to me as it is very different from all the other
remote packets announced in the NEWS file, therefore I was looking at the
protocol how is this packet special.  How can be ':' a part of the packet name
when ':' is a parameter delimiter?  And I haven't found anything special on
this packet.

Similarly the qSupported looked special to me and again it does not seem to be
anyhow special.  Even "N stop reply" announced right above uses the standard
template.

Besides that all IMO one of the purposes of the NEWS file is to be brief.

Sure I do not mind but I was reviewing a derived downstream documentation and
I just found it.


Jan
  

> Date: Sun, 29 May 2016 19:50:32 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org, philippe.waroquiers@skynet.be,
>         sergiodj@redhat.com, palves@redhat.com, xdje42@gmail.com,
>         scox@redhat.com, jistone@redhat.com
> 
> On Sun, 29 May 2016 19:29:19 +0200, Eli Zaretskii wrote:
> > Is it really that bad?  I generally tend to let people say things in
> > their own words, as long as it's readable.  But if you insist...
> 
> That :1 and :0 was confusing to me as it is very different from all the other
> remote packets announced in the NEWS file, therefore I was looking at the
> protocol how is this packet special.  How can be ':' a part of the packet name
> when ':' is a parameter delimiter?  And I haven't found anything special on
> this packet.
> 
> Similarly the qSupported looked special to me and again it does not seem to be
> anyhow special.  Even "N stop reply" announced right above uses the standard
> template.
> 
> Besides that all IMO one of the purposes of the NEWS file is to be brief.
> 
> Sure I do not mind but I was reviewing a derived downstream documentation and
> I just found it.

If you feel strongly about this, please go ahead and commit.

Thanks.
  

On Sun, 29 May 2016 20:18:13 +0200, Eli Zaretskii wrote:
> If you feel strongly about this, please go ahead and commit.

Checked in:
	aab3c527d779a8e833a469203336afcc17512559


Thanks,
Jan