From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14360 invoked by alias); 10 Feb 2009 16:18:17 -0000 Received: (qmail 14352 invoked by uid 22791); 10 Feb 2009 16:18:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 16:18:10 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id CC2DC290041; Tue, 10 Feb 2009 17:18:05 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeWZWbOJsTAL; Tue, 10 Feb 2009 17:18:05 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 9C610290045; Tue, 10 Feb 2009 17:18:04 +0100 (CET) Cc: gdb@sourceware.org, Mark Kettenis , drow@false.org Message-Id: <2730E79B-A022-43ED-86B9-BED442D2A733@adacore.com> From: Tristan Gingold To: Pedro Alves In-Reply-To: <200902101606.23591.pedro@codesourcery.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Regression Date: Tue, 10 Feb 2009 16:18:00 -0000 References: <200902101517.n1AFH7YP000549@brahms.sibelius.xs4all.nl> <20090210152657.GA27195@caradoc.them.org> <200902101547.n1AFlMsC025262@brahms.sibelius.xs4all.nl> <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/msg00082.txt.bz2 On Feb 10, 2009, at 5:06 PM, Pedro Alves wrote: > (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. Fun: at the same time I was trying to fix the regression for darwin/x86. I don't really understand the semantic of resume(step=1, signal=30). Does it mean first step and then send a signal ? If so wouldn't be simpler for targets if infrun ran two separate operations ? Tristan.