RE: async operation

Mark Newman
2003-12-04T22:09:04Z

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
>