From: Hui Zhu <hui_zhu@mentor.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: <gdb-patches@sourceware.org>, <stan_shebs@mentor.com>
Subject: Re: [PATCH] Add autoload-breakpoints [3/7] ReportAsync-doc
Date: Mon, 26 Mar 2012 02:21:00 -0000 [thread overview]
Message-ID: <4F6FD290.1070704@mentor.com> (raw)
In-Reply-To: <4F6A92F7.6090500@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]
Hi Eli,
I post a new version patch according to your mail. Please help me review.
Thanks,
Hui
2012-03-26 Hui Zhu <hui_zhu@mentor.com>
* 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<hui_zhu@mentor.com>
>>> CC:<gdb-patches@sourceware.org>,<stan_shebs@mentor.com>
>>>
>>>>>>> +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
[-- Attachment #2: report-doc.txt --]
[-- Type: text/plain, Size: 1554 bytes --]
---
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
next prev parent reply other threads:[~2012-03-26 2:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 8:52 Hui Zhu
2012-03-17 10:12 ` Eli Zaretskii
2012-03-20 13:25 ` Hui Zhu
2012-03-20 17:30 ` Eli Zaretskii
2012-03-21 7:23 ` Hui Zhu
2012-03-21 18:28 ` Eli Zaretskii
2012-03-22 2:48 ` Hui Zhu
2012-03-26 2:21 ` Hui Zhu [this message]
2012-03-31 6:04 ` Eli Zaretskii
2012-04-02 9:10 ` Hui Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F6FD290.1070704@mentor.com \
--to=hui_zhu@mentor.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=stan_shebs@mentor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox