From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1847 invoked by alias); 5 Mar 2004 16:38:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1826 invoked from network); 5 Mar 2004 16:38:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Mar 2004 16:38:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AzILe-0006CN-E0; Fri, 05 Mar 2004 11:38:54 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: gdb-patches@sources.redhat.com Subject: Re: remote debugging a multi-threaded program with signal Message-ID: <20040305163854.GA23778@nevyn.them.org> Mail-Followup-To: Atsushi Nemoto , gdb-patches@sources.redhat.com References: <20040305.000540.59461353.anemo@mba.ocn.ne.jp> <20040304222800.GA29911@nevyn.them.org> <20040305.112722.74754522.nemoto@toshiba-tops.co.jp> <20040306.014343.74756819.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040306.014343.74756819.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00106.txt.bz2 Message-ID: <20040319000900.lw2cy9kHuhP9hp73yuIPnj6h95F2kG8LnaKaBsQXpoQ@z> On Sat, Mar 06, 2004 at 01:43:43AM +0900, Atsushi Nemoto wrote: > >>>>> On Fri, 05 Mar 2004 11:27:22 +0900 (JST), Atsushi Nemoto said: > > anemo> How about when verbose-resume was disabled or unavailable? If > anemo> verbose-resume is necessary to continue with signal, gdb can > anemo> warn it for users? Or gdbserver can resume all threads on this > anemo> case? > > For gdb without verbose-resume, how about this patch? With this > patch, gdbserver uses general_thread instead of all_threads.head if > 'CNN' packet was sent without preceding 'HcNN'. > > --- gdb-6.0.90.org/gdb/gdbserver/target.c Wed Jun 12 02:32:40 2002 > +++ gdb-6.0.90/gdb/gdbserver/target.c Sat Mar 6 01:29:44 2004 > @@ -49,6 +49,10 @@ set_desired_inferior (int use_general) > if (found == NULL) > found = (struct thread_info *) find_inferior_id (&all_threads, > cont_thread); > + /* failsafe: use thread in last resume_reply */ > + if (found == NULL) > + found = (struct thread_info *) find_inferior_id (&all_threads, > + general_thread); > } > > if (found == NULL) For one thing, I'm not sure it will work. But for another, why is this case important to you? Without vCont the problem is fundamentally insoluble; there will always be a case in which gdbserver mis-guesses which thread it should continue. That's why I had to come up with a protocol change. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer