From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 472 invoked by alias); 26 Mar 2012 02:21:27 -0000 Received: (qmail 464 invoked by uid 22791); 26 Mar 2012 02:21:26 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Mar 2012 02:21:11 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SBzYU-0006Dm-Sd from Hui_Zhu@mentor.com ; Sun, 25 Mar 2012 19:21:10 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 19:21:10 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Sun, 25 Mar 2012 19:21:08 -0700 Message-ID: <4F6FD290.1070704@mentor.com> Date: Mon, 26 Mar 2012 02:21:00 -0000 From: Hui Zhu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Eli Zaretskii CC: , Subject: Re: [PATCH] Add autoload-breakpoints [3/7] ReportAsync-doc References: <4F6450D2.9030109@mentor.com> <83y5qz359r.fsf@gnu.org> <4F688533.1050705@mentor.com> <83obrr18pf.fsf@gnu.org> <4F6981D6.9040807@mentor.com> <83fwd124ia.fsf@gnu.org> <4F6A92F7.6090500@mentor.com> In-Reply-To: <4F6A92F7.6090500@mentor.com> Content-Type: multipart/mixed; boundary="------------010402090609010909050500" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00864.txt.bz2 --------------010402090609010909050500 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Content-length: 3704 Hi Eli, I post a new version patch according to your mail. Please help me review. Thanks, Hui 2012-03-26 Hui Zhu * gdb.texinfo (qSupported): Add ReportAsync. (Remote Serial Protocol): Add ReportAsync Packets. On 03/22/12 10:48, Hui Zhu wrote: > On 03/22/12 02:27, Eli Zaretskii wrote: >>> Date: Wed, 21 Mar 2012 15:23:02 +0800 >>> From: Hui Zhu >>> CC:, >>> >>>>>>> +The @value{GDBN} remote serial protocol includes @dfn{reportasync}, >>>>>>> +packets that the stub can report status or do an operation in >>>>>>> any time. >>>>>> >>>>>> I don't understand the "do an operation in any time" part. What does >>>>>> it mean in practice? >>>>> >>>>> It is means that after gdb connected with the stub, the stub can >>>>> report >>>>> when the inferior is running and GDB is waiting it, or inferior is >>>>> stoped and GDB just control it. >>>>> It make the stub can report the status for any time. >>>> >>>> You mean, as in "asynchronously"? >>> >>> Yes, that is my mean. >> >> Then please use >> >> The @value{GDBN} remote serial protocol supports @dfn{reportasync} >> that can be used asynchronously to report status or send commands. >> >>>> I still don't understand why you used the word "simple". "Simple" as >>>> opposed to what other packet handling? >>> >>> Maybe "normal" is better. "Normal" as opposed to reportasync packets. >> >> "As usual" or "usual" would be better. But see below. >> >>>>>> After the handshake, the stub can send @samp{reportasync} packets to >>>>>> @value{GDBN}, using the same packet format as in simple remote serial >>>>>> protocol. >>>>>> >>>>>> Is this only for the failed handshake? If so, perhaps we need to tell >>>>>> what happens when the handshake succeeds. >>>>> >>>>> No, this is for success. >>>> >>>> The problem here is that you again used "simple protocol", and before >>>> that you mentioned "simple packet" when the handshake failed. >>>> >>>> So this again boils down to the same question: why do you use the word >>>> "simple" in this context? >>> >>> Yes, it looks really odd even if change it to normal. That is because >>> after shakes mode, the packet will use the normal format >> >> But you said >> >> After the handshake, the stub can send @samp{reportasync} packets to >> @value{GDBN}, using the same packet format as in simple remote serial >> protocol. >> >> which actually tells me that the "normal" packets are _not_ in >> contrast with reportasync packets, since reportasync packets can be >> sent in the "normal format". What am I missing? > > Yes, after success shake hands, the stub will send packet in normal > format to GDB. > If need, GDB will answer this packets in normal format. > > For example: > static void > remote_reportasync_handler (struct remote_state *rs) > { > int len; > struct cleanup *old_chain > = make_cleanup_restore_integer (&inside_reportasync_handler); > > /* Shake hands with remote part. */ > serial_write (remote_desc, "^", 1); > > inside_reportasync_handler = 1; > > if (getpkt_sane (&rs->buf, &rs->buf_size, 0) < 0) > return; > > if (remote_debug) > fprintf_unfiltered (gdb_stdlog, "ReportAsync: %s\n", rs->buf); > > if (strncmp (rs->buf, "QBDP", strlen ("QBDP")) == 0) > { > if (parse_autoload_breakpoint_definition_to_breakpoints > (rs->buf + strlen ("QBDP")) == 0) > putpkt ("OK"); > else > putpkt ("E01"); > } > else > putpkt (""); > > do_cleanups (old_chain); > } > > This function will be call when GDB got a ^ and is OK to shake hands. > It call serial_write (remote_desc, "^", 1); to shake hands. Then call > getpkt_sane to get the package from the stub. And use putpkt reply. > > Thanks, > Hui --------------010402090609010909050500 Content-Type: text/plain; charset="us-ascii"; name="report-doc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="report-doc.txt" Content-length: 1554 --- doc/gdb.texinfo | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) --- a/doc/gdb.texinfo +++ b/doc/gdb.texinfo @@ -33661,6 +33661,7 @@ Show the current setting of the target w * Host I/O Packets:: * Interrupts:: * Notification Packets:: +* ReportAsync Packets:: * Remote Non-Stop:: * Packet Acknowledgment:: * Examples:: @@ -35567,6 +35568,10 @@ to be enabled and disabled while a trace The remote stub supports the @samp{tracenz} bytecode for collecting strings. See @ref{Bytecode Descriptions} for details about the bytecode. +@item ReportAsync +The remote stub supports the @samp{ReportAsync} packet +(@pxref{ReportAsync Packets}). + @end table @item qSymbol:: @@ -36664,6 +36669,24 @@ for information on how these notificatio @value{GDBN}. @end table +@node ReportAsync Packets +@section ReportAsync Packets +@cindex reportasync packets +@cindex packets, reportasync + +The @value{GDBN} remote serial protocol supports @dfn{reportasync} +that can be used asynchronously to report status or send commands. + +When the stub want send @dfn{reportasync} packets, it send shake hands +packet @samp{^} to @value{GDBN}. +If @value{GDBN} replies with a @samp{^}, the handshake is successful. +If not, the handshake fails, and the @samp{reportasync} packet needs +to be handled as usual. + +After the handshake, the stub can send @samp{reportasync} packets to +@value{GDBN}, using the same packet format as in normal remote serial +protocol. + @node Remote Non-Stop @section Remote Protocol Support for Non-Stop Mode --------------010402090609010909050500--