From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22137 invoked by alias); 4 Apr 2012 15:01:30 -0000 Received: (qmail 22121 invoked by uid 22791); 4 Apr 2012 15:01:25 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Apr 2012 15:01:09 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q34F0eeV026012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 11:00:53 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q34F0SWH016220; Wed, 4 Apr 2012 11:00:39 -0400 Message-ID: <4F7C620C.6050809@redhat.com> Date: Wed, 04 Apr 2012 15:01:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tristan Gingold CC: John Gilmore , gdb@sourceware.org Subject: Re: PR13901 References: <20120330134210.GA7869@bromo.med.uc.edu> <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> <4F79AFF4.9000704@redhat.com> <201204030728.q337SMWD018124@new.toad.com> <4F7C593E.5040708@redhat.com> <454D631A-B8E3-42DD-860F-9B5F5A485810@adacore.com> In-Reply-To: <454D631A-B8E3-42DD-860F-9B5F5A485810@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-04/txt/msg00043.txt.bz2 On 04/04/2012 03:47 PM, Tristan Gingold wrote: > Welcome in the Darwin team :-) ;-) > I was thinking about a slightly better way (IMHO): just call darwin_set_sstep when > the single-step flag is set or was just cleared. This should improve performance. > There might be subtile difference for signal handling, but I am not even sure that gdb behaviour is well defined in that case. Hmm, good idea. Kernel's are known to forget the trace flag around signals and I'm under the impression that darwin is one of those that can't step to signal handlers. But indeed if we always single-step when the flag is set, and only "optimize" on step->!step, it does sounds like it should work. -- Pedro Alves