From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21180 invoked by alias); 18 Feb 2005 10:33:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21052 invoked from network); 18 Feb 2005 10:33:38 -0000 Received: from unknown (HELO topsns.toshiba-tops.co.jp) (202.230.225.5) by sourceware.org with SMTP; 18 Feb 2005 10:33:38 -0000 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for sourceware.org [12.107.209.250]) with SMTP; 18 Feb 2005 10:33:38 UT Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 6C36E1EAE2; Fri, 18 Feb 2005 19:33:37 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 5F2801839E; Fri, 18 Feb 2005 19:33:37 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j1IAXX9c035855; Fri, 18 Feb 2005 19:33:33 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 18 Feb 2005 22:54:00 -0000 Message-Id: <20050218.193333.07644163.nemoto@toshiba-tops.co.jp> To: drow@false.org Cc: gdb@sources.redhat.com Subject: Re: huge remote debug traffic with multi-thread program From: Atsushi Nemoto In-Reply-To: <20050217.104200.93020045.nemoto@toshiba-tops.co.jp> References: <20050216.210432.15259170.nemoto@toshiba-tops.co.jp> <20050216165909.GA11396@nevyn.them.org> <20050217.104200.93020045.nemoto@toshiba-tops.co.jp> 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: 2005-02/txt/msg00119.txt.bz2 >>>>> On Thu, 17 Feb 2005 10:42:00 +0900 (JST), Atsushi Nemoto said: anemo> Looking the log, gdbserver keep getting SIGTRAP on 0x00404a78 anemo> (__pthread_wait_for_restart_signal+132). This is a return anemo> address from __pthread_sigsuspend() which is a stopping place anemo> of SIGINT (Ctrl-C). I'm wondering why gdb set breakpoint to anemo> the return address of __pthread_sigsuspend() ... The reason was gdb is doing software single-step on resuming. The instruction on stop_pc is 'jr ra' in __pthread_sigsuspend. When resuming, gdb set breakpoint of the return address to do software single-stop. Next question is why gdb try to do single step here. It seems due to this code in infrun.c:proceed(). 712: else if (gdbarch_single_step_through_delay_p (current_gdbarch) 713: && gdbarch_single_step_through_delay (current_gdbarch, 714: get_current_frame ())) 715: /* We stepped onto an instruction that needs to be stepped 716: again before re-inserting the breakpoint, do so. */ 717: oneproc = 1; On mips, gdbarch_single_step_through_delay return 1 for 'jr' instruction. In gdb 6.3, it was: 732: if (STEP_SKIPS_DELAY_P 732: && breakpoint_here_p (read_pc () + 4) 732: && STEP_SKIPS_DELAY (read_pc ())) 732: oneproc = 1; and ChangeLog saied: 2004-10-31 Orjan Friberg Andrew Cagney * gdbarch.sh (single_step_through_delay): Add. * gdbarch.h, gdbarch.c: Re-generate. * config/mips/tm-mips.h (STEP_SKIPS_DELAY_P, STEP_SKIPS_DELAY) (mips_step_skips_delay): Delete. * mips-tdep.c (mips_single_step_through_delay): Replace mips_step_skips_delay. (mips_gdbarch_init): Set single_step_through_delay. (mips_dump_tdep): Do not print STEP_SKIPS_DELAY. It seems "breakpoint_here_p (read_pc() + 4)" test was lost. Is this intentional? Thank you. --- Atsushi Nemoto