From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17970 invoked by alias); 10 Feb 2009 18:40:38 -0000 Received: (qmail 17960 invoked by uid 22791); 10 Feb 2009 18:40:37 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 18:40:28 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n1AId5XD001612; Tue, 10 Feb 2009 19:39:05 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n1AId4Mb031903; Tue, 10 Feb 2009 19:39:04 +0100 (CET) Date: Tue, 10 Feb 2009 18:40:00 -0000 Message-Id: <200902101839.n1AId4Mb031903@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb@sourceware.org, drow@false.org In-reply-to: <200902101800.35832.pedro@codesourcery.com> (message from Pedro Alves on Tue, 10 Feb 2009 18:00:35 +0000) Subject: Re: Regression References: <200902101517.n1AFH7YP000549@brahms.sibelius.xs4all.nl> <200902101547.n1AFlMsC025262@brahms.sibelius.xs4all.nl> <200902101606.23591.pedro@codesourcery.com> <200902101800.35832.pedro@codesourcery.com> 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/msg00086.txt.bz2 > From: Pedro Alves > Date: Tue, 10 Feb 2009 18:00:35 +0000 Thanks Pedro, for looking into this! > 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. Indeed. OpenBSD/i386 (as well as NetBSD, FreeBSD and probably Darwin) clears the trace bit before running the signal handler. I've looked at the PR mentioned in the commi message, and I don't quite understand how the change to the signal command has anything to do with that.