From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-16484-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 22673 invoked by alias); 4 Dec 2003 22:09:04 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 22658 invoked from network); 4 Dec 2003 22:09:03 -0000
Received: from unknown (HELO web13802.mail.yahoo.com) (216.136.175.12)
  by sources.redhat.com with SMTP; 4 Dec 2003 22:09:03 -0000
Message-ID: <20031204220900.11079.qmail@web13802.mail.yahoo.com>
Received: from [24.59.142.117] by web13802.mail.yahoo.com via HTTP; Thu, 04 Dec 2003 14:09:00 PST
Date: Thu, 04 Dec 2003 22:09:00 -0000
From: Mark Newman <markn_46@yahoo.com>
Subject: RE: async operation
To: Elena Zannoni <ezannoni@redhat.com>,
  "Newman, Mark \(N-Superior Technical Resource Inc\)" <mark.newman@lmco.com>
Cc: Mark Newman <markn_46@yahoo.com>, gdb@sources.redhat.com
In-Reply-To: <16335.41122.634794.412421@localhost.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-12/txt/msg00091.txt.bz2

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
>