From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27428 invoked by alias); 10 Feb 2015 17:40:31 -0000 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 Received: (qmail 26557 invoked by uid 89); 10 Feb 2015 17:40:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 10 Feb 2015 17:40:30 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1AHeRsH017024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 10 Feb 2015 12:40:28 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1AHePFP001977; Tue, 10 Feb 2015 12:40:26 -0500 Message-ID: <54DA4289.4090701@redhat.com> Date: Tue, 10 Feb 2015 17:40:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jan Kratochvil , gdb-patches@sourceware.org CC: Phil Muldoon Subject: Re: [PATCH 0/6] framefilter quit: PR cli/17716 References: <20150207144501.14897.90709.stgit@host1.jankratochvil.net> In-Reply-To: <20150207144501.14897.90709.stgit@host1.jankratochvil.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00269.txt.bz2 Hi Jan, I read this, and it looks pretty good to me. Phil, any comments? Thanks, Pedro Alves On 02/07/2015 02:45 PM, Jan Kratochvil wrote: > Hi Phil, > > as I have seen gdb-7.9 may get released with this annoying bug I have attempted > a fix. It is far from complete but it should hopefully handle most of the > uninterruptable cases - although some of them will apparently still remain > there. > > Primarily I do not understand intentions of the code: > > gdbpy_convert_exception() is required in code called from Python, such as for > bpfinishpy_init() as one of many examples. But if I haven't make mistake I do > not see any of the GDB functions changed in this patchset (py_print_single_arg, > enumerate_locals, py_print_frame) would be called by Python. Therefore I do > not see why they should call gdbpy_convert_exception() at all (moreover they > call it so many times). These functions are normally called by GDB and GDB is > GDB exception safe so GDB exceptions can be safely thrown. Not all of the > gdb/python/ code was GDB exception safe, this is why I had to change for > example also gdbpy_apply_frame_filter(). I find more safe to write code as > exception safe in general. Hopefully I did not forget to make exception safe > any of the possible callers of the involved functions. > > Then I do not understand why there is EXT_LANG_BT_ERROR. GDB has exceptions so > it does not need error return values. Error return values can be used in cases > when it is more simple for the code (As current implementation of GDB > exceptions is needlessly complicated to use) - when callee detects a problem on > its own. But if caller has to TRY_CATCH exceptions from futher callees and > convert them into EXT_LANG_BT_ERROR so that its caller can check for > EXT_LANG_BT_ERROR... Why hasn't the caller just do TRY_CATCH on its own? > I haven't tried to remove EXT_LANG_BT_ERROR at all myself in this patchset, > though. That would be larger work. > > As I said the patch is not complete but I believe the direction of this patch > is correct and futher fixes can extend it.