From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28192 invoked by alias); 5 Mar 2004 02:25:07 -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 27706 invoked from network); 5 Mar 2004 02:25:06 -0000 Received: from unknown (HELO topsns.toshiba-tops.co.jp) (202.230.225.5) by sources.redhat.com with SMTP; 5 Mar 2004 02:25:06 -0000 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for sources.redhat.com [67.72.78.213]) with SMTP; 5 Mar 2004 02:25:12 UT Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i252Ou1x091394; Fri, 5 Mar 2004 11:24:56 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-Id: <20040305.112722.74754522.nemoto@toshiba-tops.co.jp> To: drow@false.org Cc: gdb-patches@sources.redhat.com Subject: Re: remote debugging a multi-threaded program with signal From: Atsushi Nemoto In-Reply-To: <20040304222800.GA29911@nevyn.them.org> References: <20040304.010624.59462252.anemo@mba.ocn.ne.jp> <20040305.000540.59461353.anemo@mba.ocn.ne.jp> <20040304222800.GA29911@nevyn.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00078.txt.bz2 >>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz said: drow> I thought you said you got the same results without drow> verbose-resume? Oh, I suppose you would; without verbose-resume drow> it's pot-luck which thread gets the signal. drow> If I use a pre-vCont gdb client with the current gdbserver I drow> see: drow> [sigtest:30016:16384]:main drow> [sigtest:30018:16386]:func drow> [sigtest:30016:16384]:send SIGUSR1 drow> [sigtest:30016:16384]:send SIGUSR1 Oh yes, I got the same result without verbose-reume, but I did not see any ':sigwait 10' messages on another machine. drow> That resumes only the thread in question. This is in drow> target-indepenedent code and the only reason that lin-lwp native drow> execution does not show the same problem is that it shortcuts drow> around this code completely (see lin_lwp_wait). You mean following code in lin_lwp_wait (lin-lwp.c:1518) ? if (signal_stop_state (signo) == 0 && signal_print_state (signo) == 0 && signal_pass_state (signo) == 1) { /* FIMXE: kettenis/2001-06-06: Should we resume all threads here? It is not clear we should. GDB may not expect It shourcuts the code on "noprint" case, but not on "nostop" case. So I suppose native execution also have this problem. drow> Could you try this instead? Thank you. It works well with verbose-resume. How about when verbose-resume was disabled or unavailable? If verbose-resume is necessary to continue with signal, gdb can warn it for users? Or gdbserver can resume all threads on this case? --- Atsushi Nemoto From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28192 invoked by alias); 5 Mar 2004 02:25:07 -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 27706 invoked from network); 5 Mar 2004 02:25:06 -0000 Received: from unknown (HELO topsns.toshiba-tops.co.jp) (202.230.225.5) by sources.redhat.com with SMTP; 5 Mar 2004 02:25:06 -0000 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for sources.redhat.com [67.72.78.213]) with SMTP; 5 Mar 2004 02:25:12 UT Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i252Ou1x091394; Fri, 5 Mar 2004 11:24:56 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 05 Mar 2004 02:25:00 -0000 Message-ID: <20040305.112722.74754522.nemoto@toshiba-tops.co.jp> To: drow@false.org Cc: gdb-patches@sources.redhat.com Subject: Re: remote debugging a multi-threaded program with signal From: Atsushi Nemoto In-Reply-To: <20040304222800.GA29911@nevyn.them.org> References: <20040304.010624.59462252.anemo@mba.ocn.ne.jp> <20040305.000540.59461353.anemo@mba.ocn.ne.jp> <20040304222800.GA29911@nevyn.them.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00078.txt Message-ID: <20040305022500.a-0nR1eos_D_NGJmdJniPDuOFi2o2P9b2gFjVaE2QDM@z> >>>>> On Thu, 4 Mar 2004 17:28:00 -0500, Daniel Jacobowitz said: drow> I thought you said you got the same results without drow> verbose-resume? Oh, I suppose you would; without verbose-resume drow> it's pot-luck which thread gets the signal. drow> If I use a pre-vCont gdb client with the current gdbserver I drow> see: drow> [sigtest:30016:16384]:main drow> [sigtest:30018:16386]:func drow> [sigtest:30016:16384]:send SIGUSR1 drow> [sigtest:30016:16384]:send SIGUSR1 Oh yes, I got the same result without verbose-reume, but I did not see any ':sigwait 10' messages on another machine. drow> That resumes only the thread in question. This is in drow> target-indepenedent code and the only reason that lin-lwp native drow> execution does not show the same problem is that it shortcuts drow> around this code completely (see lin_lwp_wait). You mean following code in lin_lwp_wait (lin-lwp.c:1518) ? if (signal_stop_state (signo) == 0 && signal_print_state (signo) == 0 && signal_pass_state (signo) == 1) { /* FIMXE: kettenis/2001-06-06: Should we resume all threads here? It is not clear we should. GDB may not expect It shourcuts the code on "noprint" case, but not on "nostop" case. So I suppose native execution also have this problem. drow> Could you try this instead? Thank you. It works well with verbose-resume. How about when verbose-resume was disabled or unavailable? If verbose-resume is necessary to continue with signal, gdb can warn it for users? Or gdbserver can resume all threads on this case? --- Atsushi Nemoto