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

[Hui Zhu <teawater at gmail dot com>]

On Tue, May 15, 2012 at 7:26 PM, Hui Zhu <teawater@gmail.com> wrote:
> 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

Ping.

Thanks,
Hui