From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19525 invoked by alias); 7 Jul 2009 10:42:04 -0000 Received: (qmail 19503 invoked by uid 22791); 7 Jul 2009 10:42:02 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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, 07 Jul 2009 10:41:54 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id EE6BC290008; Tue, 7 Jul 2009 12:41:51 +0200 (CEST) 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 oPJYGjSc--0c; Tue, 7 Jul 2009 12:41:51 +0200 (CEST) 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 4CEFA290001; Tue, 7 Jul 2009 12:41:51 +0200 (CEST) Cc: gdb-patches@sourceware.org Message-Id: <09E70B0B-1B71-443C-B5A2-23F1FDE7E06D@adacore.com> From: Tristan Gingold To: Mark Kettenis In-Reply-To: <200907070943.n679hRt8029389@brahms.sibelius.xs4all.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [RFA Darwin]: handle simultaneous signal posting and single-stepping Date: Tue, 07 Jul 2009 10:42:00 -0000 References: <200907070943.n679hRt8029389@brahms.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00186.txt.bz2 On Jul 7, 2009, at 11:43 AM, Mark Kettenis wrote: >> >> This patch fixes the issue by first single-stepping and keeping in >> mind that a signal has to be posted. > > I'm not sure that single-stepping before sending the signal is right. > This means we'll execute an instruction (which potentially affects the > way signals are handled) before the program actually sees the signal. > > I think a better way to do this is to continue with a signal while > keeping the breakpoints inserted, and deal with hitting the breakpoint > again in the appropriate way. Doesn't this change the gdb behaviour ? I have no strong opinion on this but this is generally a concern. > Also, I think this needs to be handled in the generic code. I'm > facing the same problem on OpenBSD. Interesting. So I have to work on infrun.c... Thanks for the comment, Tristan.