From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30729 invoked by alias); 10 Feb 2009 16:06:34 -0000 Received: (qmail 30721 invoked by uid 22791); 10 Feb 2009 16:06:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 16:06:24 +0000 Received: (qmail 12078 invoked from network); 10 Feb 2009 16:06:20 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Feb 2009 16:06:20 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Regression Date: Tue, 10 Feb 2009 16:06:00 -0000 User-Agent: KMail/1.9.10 Cc: Mark Kettenis , drow@false.org References: <200902101517.n1AFH7YP000549@brahms.sibelius.xs4all.nl> <20090210152657.GA27195@caradoc.them.org> <200902101547.n1AFlMsC025262@brahms.sibelius.xs4all.nl> In-Reply-To: <200902101547.n1AFlMsC025262@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902101606.23591.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00081.txt.bz2 On Tuesday 10 February 2009 15:47:23, Mark Kettenis wrote: > I don't quite understand what's happening here, but I get the > following new failure: > > FAIL: gdb.base/annota1.exp: send SIGUSR1 > I see that too. > and some more fallout from that (and similar failures in annota3.exp). > It seems that if we've just hit a breakpoint and then do "signal > SIGUSR1" we never enter the signal handler or ignore the breakpoint in > the signal handler. Here's the infrun log on i386-openbsd4.3: (gdb) b printf Breakpoint 1 at 0x1c000408 (gdb) r Starting program: /net/home/pedro/gdb/baseline/build-openbsd43/gdb/testsuite/gdb.base/annota1 Breakpoint 1, printf (fmt=0x3c000001 "value is %d\n") at /usr/src/lib/libc/stdio/printf.c:43 43 /usr/src/lib/libc/stdio/printf.c: No such file or directory. in /usr/src/lib/libc/stdio/printf.c (gdb) p $pc $1 = (void (*)()) 0xa43a633 (gdb) b handle_USR1 Breakpoint 2 at 0x1c000613: file ../../../src/gdb/testsuite/gdb.base/annota1.c, line 18. (gdb) set debug infrun 1 (gdb) signal SIGUSR1 Continuing with signal SIGUSR1. infrun: clear_proceed_status_thread (process 27276) infrun: proceed (addr=0xffffffff, signal=30, step=0) infrun: resume (step=1, signal=30), trap_expected=1 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = 27276, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xeff4636 Here, it seems like telling BSD to single-step, and, to deliver a signal at the same time, just single-steps, resulting in a SIGTRAP. infrun: no stepping, continue infrun: resume (step=0, signal=0), trap_expected=0 infrun: prepare_to_wait value is 7 infrun: target_wait (-1, status) = 27276, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xeff4633 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_stepping Breakpoint 1, printf (fmt=0x3c00000e "my_array[2] is %d\n") at /usr/src/lib/libc/stdio/printf.c:43 43 in /usr/src/lib/libc/stdio/printf.c (gdb) > > I'm somewhat surprised to hear that the same test doesn't fail on x86 > Linux for you. It doesn't for me. -- Pedro Alves