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

[Pedro Alves <palves at redhat dot com>]

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