From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10414 invoked by alias); 31 Oct 2013 13:27:26 -0000 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 Received: (qmail 10395 invoked by uid 89); 31 Oct 2013 13:27:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e24smtp03.br.ibm.com Received: from e24smtp03.br.ibm.com (HELO e24smtp03.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 31 Oct 2013 13:27:24 +0000 Received: from /spool/local by e24smtp03.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 31 Oct 2013 11:27:20 -0200 Received: from d24dlp01.br.ibm.com (9.18.248.204) by e24smtp03.br.ibm.com (10.172.0.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 31 Oct 2013 11:27:19 -0200 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by d24dlp01.br.ibm.com (Postfix) with ESMTP id 8FCFE3520054 for ; Thu, 31 Oct 2013 09:27:18 -0400 (EDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.8.31.91]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9VDRLbt1294414 for ; Thu, 31 Oct 2013 11:27:21 -0200 Received: from d24av01.br.ibm.com (localhost [127.0.0.1]) by d24av01.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r9VDRIgQ009608 for ; Thu, 31 Oct 2013 11:27:18 -0200 Received: from [9.78.131.209] ([9.78.131.209]) by d24av01.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r9VDRHQ8009589; Thu, 31 Oct 2013 11:27:18 -0200 Message-ID: <52725AB4.5080002@linux.vnet.ibm.com> Date: Thu, 31 Oct 2013 13:27:00 -0000 From: Edjunior Barbosa Machado User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?UTF-8?B?VGlhZ28gU3TDvHJtZXIgRGFpdHg=?= , GDB Development Subject: Re: Get longjmp target check in breakpoint.c - is it necessary? References: <1383186973.5925.103.camel@localhost.localdomain> In-Reply-To: <1383186973.5925.103.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13103113-9254-0000-0000-00000E1948F9 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00192.txt.bz2 Hi Tiago, On 10/31/2013 12:36 AM, Tiago Stürmer Daitx wrote: > We have in gdb/breakpoint.c the following condition checking: > > 3222 if (!gdbarch_get_longjmp_target_p (gdbarch))¬ > 3223 » continue;¬ > > Which is forcing me to implement an (unnecessary?) arch specific > get_longjmp_target while having a longjmp user probe in glibc should be > enough. Removing that if/continue statement showed no regressions - it > actually fixed 3 longjmp failures (assuming proper support in glibc for > a longjmp probe is in place). If I understood correctly, there are different longjmps symbols search strategies on this create_longjmp_master_breakpoint() function: the recent libc probe search and the per-objfile cache lookup. It seems this 'if' works like an optimization to avoid searching for symbols if the arch didn't provide support for get_longjmp_target(). However, _get_longjmp_target() function became unnecessary in targets that provide libc probe support, as you noticed with the addition of probes on ppc64 glibc. What if you try to move this 'if' to a bit below in the function (right before "for (i = 0; i < NUM_LONGJMP_NAMES; i++)" loop)? Thanks and regards, -- Edjunior