RE: async operation

[Mark Newman <markn_46 at yahoo dot com>]

I did fix this.  If you look at the patch I put in you
will see a reference to ASYNC_WAIT.  When this bit is
set (as it will be for "interrupt" and "quit"} gdb
waits for a response from gdbserver when in async.

This manner of "fixing" the problem should go away
when the select in event_top, etc is combined with the
select fr the remote target.

This set of changes was designed to be under 20 lines.

                           Mark

--- Elena Zannoni <ezannoni@redhat.com> wrote:
> Newman, Mark (N-Superior Technical Resource Inc)
> writes:
>  > IMHO async is not an invention of the client but
> the manner in which gdb
>  > controls the client. ;-)
>  > 
>  > I am attaching a gdb output with remote_debug
> set.  In this instance the
>  > sequence
>  > 
>  > > interrupt
>  > > cont &
>  > 
>  > worked once but did not work the second time.
> 
> [...]
>  > 
>  > It may be my changes that are causing the
> problem.
>  
> Can you try on a gdb w/o your modifications?
> 
> 
>  > 
>  > Program received signal SIGINT, Interrupt.
>  > Sending packet: $M4000acb0,1:55#68...Ack
>  > Packet received: ENN
>  > Sending packet: $M4000acb0,1:55#68...Ack
>  > Packet received: ENN
>  > Sending packet: $mbffff830,4#62...Ack
>  > Packet received: 55320000
>  > Sending packet: $mbffff834,4#66...Ack
>  > Packet received: 55320000
>  > 0x080483f7 in main (argc=12885, argv=0x3255) at
> main.c:52
>  > 52      while (j < 1000000) {
> 
> I assume you said continue here?
> 
>  > 
>  > Sending packet: $c#63...Ack
>  > 
>  > remote_stop called
> 
> Hmm do you see any output that says that
> remote_interrupt has been
> called as well? I wonder if the signal handlers are
> screwed up.
> 
>  > 
>  > Sending packet: $c#63...Packet instead of Ack,
> ignoring it
> 
> gdb keeps issuing the continue command for some
> reason. maybe it
> hasn't realized that the target is actually running.
> 
> 
> elena
>