From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31988 invoked by alias); 10 Feb 2009 18:00:43 -0000 Received: (qmail 31978 invoked by uid 22791); 10 Feb 2009 18:00:41 -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 18:00:34 +0000 Received: (qmail 16042 invoked from network); 10 Feb 2009 18:00:32 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Feb 2009 18:00:32 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Regression Date: Tue, 10 Feb 2009 18:00:00 -0000 User-Agent: KMail/1.9.10 Cc: Mark Kettenis , drow@false.org References: <200902101517.n1AFH7YP000549@brahms.sibelius.xs4all.nl> <200902101547.n1AFlMsC025262@brahms.sibelius.xs4all.nl> <200902101606.23591.pedro@codesourcery.com> In-Reply-To: <200902101606.23591.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902101800.35832.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/msg00085.txt.bz2 Opps, my logs didn't show something as clearly as I indended: > $1 = (void (*)()) 0xa43a633 vs > 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. Errr, here it tells that I re-ran the inferior to get first PC, after having pased the stop_pc bit already, from a previous run. Different runs, different PCs, notice the randomization affecting the first bytes of the addresses. Sorry for any confusion it may have caused. Here's a run, to show how OpenBSD forgets to single-step into the handler: (gdb) p $pc $1 = (void (*)()) 0x51b0633 (gdb) signal SIGUSR1 Continuing with signal SIGUSR1. infrun: clear_proceed_status_thread (process 18606) 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) = 18606, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x51b0636 Then, I've added a printf in the signal handler itself, to see if it runs at all: (gdb) signal SIGUSR1 Continuing with signal SIGUSR1. infrun: clear_proceed_status_thread (process 1505) 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) handle_USR1 ^^^^^^^^^^^ (1) infrun: target_wait (-1, status) = 1505, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x6919636 infrun: no stepping, continue infrun: resume (step=0, signal=0), trap_expected=0 ^^^^^^^^^^^^^^ (2) infrun: prepare_to_wait my_array[2] is 3 infrun: target_wait (-1, status) = 1505, status->kind = exited, status = 0 infrun: infwait_normal_state infrun: TARGET_WAITKIND_EXITED So, it does run, according to (1) above, but, since we were stepping over a breakpoint notice (trap_expected=1), GDB had removed breakpoints from the inferior. They're only inserted on the following resume, at (2). That's why you miss the breakpoint in the signal handler. Without Daniel's patch, "signal FOO" *would not remove breakpoints*, since it was calling `proceed' like if it was a "jump". Here's the same on i386-linux: Breakpoint 1, 0x00007ffff784ae40 in printf () from /lib/libc.so.6 (gdb) set debug infrun 1 (gdb) signal SIGUSR1 Continuing with signal SIGUSR1. infrun: clear_proceed_status_thread (process 17569) infrun: proceed (addr=0xffffffffffffffff, 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) = 17569, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400528 ^^^^^^^^^^^^^^^^^^ infrun: no stepping, continue infrun: resume (step=0, signal=0), trap_expected=0 infrun: prepare_to_wait infrun: target_wait (-1, status) = 17569, status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40052f infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_stepping Breakpoint 2, handle_USR1 (sig=10) at ../../../src/gdb/testsuite/gdb.base/annota1.c:19 19 } That stop was a finished single-step to the start of the signal handler: (gdb) disassemble 0x400528 (0x400528 + 100) Dump of assembler code from 0x400528 to 0x40058c: 0x0000000000400528 : push %rbp 0x0000000000400529 : mov %rsp,%rbp 0x000000000040052c : mov %edi,-0x4(%rbp) 0x000000000040052f : leaveq 0x0000000000400530 : retq (...) So, linux can single-step into a signal handler, OpenBSD doesn't. -- Pedro Alves