Re: [PATCH v2] Add autoload-breakpoints [1/6] ReportAsync

[Hui Zhu <teawater at gmail dot com>]

On Tue, May 15, 2012 at 1:33 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/26/2012 10:44 AM, Yao Qi wrote:
>
>> On 04/11/2012 06:54 PM, Hui Zhu wrote:
>>> To make the remote stub control the autoload-breakpoints in GDB part. ?I
>>> add ReportAsync function.
>>> I think there must somebody ask me how different ReportAsync Packets and
>>> Notification Packets. There are some introduce:
>>>
>>> 1. The Notification should happen when GDB RSP package just send to the
>>> stub.
>>> But ReportAsync should not. ?ReportAsync need do a shake hands with GDB
>>> first. ?So when this is not the right time to handle the control packat
>>> from the stub (for example: when gdb just send a packet to remote, do a
>>> another control maybe affect gdb). ?GDB can ignore this shake hands
>>> directly. ?Then the stub can give up this operation and wait for the
>>> another time try again.
>>> With this support, we can let the stub use ReportAsync do some spcial
>>> operation to GDB.
>>>
>>> 2. Because after shake hands, another package will translate with ack,
>>> it will be more safe in some remote infterface then Notification.
>>
>> Usually, if a patch is pending for review around two weeks, I guess it
>> is caused by either this patch is not justified properly to go in or
>> maintainers red patch but gave up giving some comments due to some
>> reasons. :-) ?I try to explain something more, and hope it is helpful to
>> encourage people here to give their comments, and finally get it
>> approved hopefully. ?:)
>>
>> "ReportAsync", which can exist out of autoload-breakpoints, is a quite
>> fundamental and useful feature current GDB RSP is missing. ?In current
>> RSP specification, nothing equivalent to "ReportAsync" can reliably
>> (more reliable than notification packet) report from gdb stub to GDB
>> about the target side situation. ?Although it is a challenge to
>> guarantee "ReportAsync" is reliable in the stateful remote.c code, ?we
>> need it to build something great on top of it:
>>
>> ? 1) Report something to GDB actively. ?This is similar to what
>> notifications do, but it is more reliable.
>> ? 2) Execute some commands on host side. ?Unlike target-side commands
>> (such as `dprintf'
>> http://sourceware.org/ml/gdb-patches/2012-02/msg00689.html), remote
>> target may need to adjust GDB's state by executing some host-side
>> commands under certain circumstance, for instance, disable a breakpoint,
>> start tracing, and turn on displaced stepping. ?They may be triggered by
>> some dynamically computed data. ?By means of "ReportAsync", remote stub
>> can send some quests to GDB to execute commands on host side easily.
>>
>> Unfortunately, we don't have "ReportAsync" used in GDBserver. ?I planed
>> to use it to handle "tracebuffer is full", but current approach using
>> breakpoint is better because threads are stopped when GDB tries to read
>> inferior's address. ?We are still looking for the cases can use
>> "ReportAsync".
>>
>> If you have questions/objections/disagreements, feel free to let us know.
>>
>
>
> I've tried to read these explanations more than once, and I still don't
> understand what is the problem being solved that can't be solved with
> new notifications. ?Can't someone explain what is the problem that needs
> solving, instead of jumping to a solution?
>
> Thanks,
>
> --
> Pedro Alves

Thanks.  That is a very good question.

I will introduce my thought about it.

The notification's introduce is "The gdb remote serial protocol
includes notifications, packets that require no acknowledgment."
All it's handler inside the packet handle in the remote.c, for example:
	    case '%':
	      {
		int val;

		/* If we got a notification, handle it, and go back to looking
		   for an ack.  */
		/* We've found the start of a notification.  Now
		   collect the data.  */
		val = read_frame (&rs->buf, &rs->buf_size);
		if (val >= 0)

The good point is this packet can be handle anytime.
But the weak point is:
1. this packet cannot supply ack in its design, because it will affect
current packet translate.   And GDB cannot translate back in this
packet translate section because GDBserver is turn to handle the
packet that GDB just send.
So it cannot supply a interface like normal GDBrsp packet does, for
examle: gdb send a control packet to gdbserver.  Gdbserver reply a
"OK" or "Exx".
2. The notifications packet cannot support an operation for example
autoload-breakpoint remove.  Because GDB will get a notifications that
it just begin to do an operation. In that status, GDB just have 2 ways
to handle it:
Way 1, do it.  That will affect the operation that GDB just did.
Way 2, give up.  Like what I said in 1, GDB cannot send a packet back
to gdbserver to let it know this operation is give up.

Of course, we can put this operation to an queue or something,  and
handle it later.  And use an notification back to gdbserver.  But I
though its make all this work hard for design for both gdb and
gdbserver.

The prev part is about why I make report-async.
Like notification, report-async can be handle for anytime.
But different with notifications, it shake hands first.  If shake
hands OK, gdbserver will translate packet use normal rsp format, and
gdb can reply it.
If GDB is not OK to handle the report-async for example, it just send
a packet to gdbserver.  It can give up this shake hands.  Then
gdbserver will know this shake hand is fail.  It can turn to handle
the packet from gdb.  After that, try to shake hands again.

Thanks,
Hui