From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21383 invoked by alias); 12 May 2011 19:00:33 -0000 Received: (qmail 21373 invoked by uid 22791); 12 May 2011 19:00:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 May 2011 19:00:14 +0000 Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p4CJ0DqR002519 for ; Thu, 12 May 2011 12:00:13 -0700 Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by hpaq1.eem.corp.google.com with ESMTP id p4CIveL7010835 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 12:00:11 -0700 Received: by gxk10 with SMTP id 10so954079gxk.39 for ; Thu, 12 May 2011 12:00:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.193.5 with SMTP id q5mr640564ybf.96.1305226811297; Thu, 12 May 2011 12:00:11 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Thu, 12 May 2011 12:00:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2011 19:00:00 -0000 Message-ID: Subject: Re: [RFC] Python Finish Breakpoints From: Doug Evans To: Kevin Pouget Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2011-05/txt/msg00054.txt.bz2 Hi. re: On Mon, May 9, 2011 at 7:10 AM, Kevin Pouget wrote: > Hello, > > I would like to discuss with you guys a new Python interface for > breakpoint handling. Based on the `finish' command, I prepared a > Python class which allows to catch the return of a given frame. > Basically, the motivation behind this class is to allow Python script > to wrap inferior function calls: > > with a code like > int do_something(int *a) > { > =A0 *a +=3D 5; > =A0 sleep(a); > =A0 return 10; > } > which may take a few seconds to execute, there was no way to know the > updated value of `a' and the return value (`gdb.execute("finish")' > could do that, but a Ctrl^C during the `sleep' would have screwed up > your results). Plus >But globally, my thoughts when I prepared this interface were that it >shouldn't be much different from a classic breakpoint. I'm not really >familiar with C++ mechanisms, but I can't see (right now, but I'll >investigate it) how it differs from setting a BP on the frame above, >checking for recursion upon BP hit and checking for the scope every >once in a while. This *may* be a reasonable approach in the end, and I am sensitive to the time invested (that's why I'm replying ... I'd hate for too much time being spent hacking down a path that ultimately gets abandoned), but I wonder if another approach would be better. I honestly don't know if it is, but it feels like it should at least be discussed. To me, there's a difference between providing robust handling a hand-called function finishing and a general "finish" handler. The semantics are sufficiently different, e.g. w.r.t. longjmp/c++-exception. So first let me ask a clarifying question: Is the main purpose for the patch to provide robust handling of the different ways an inferior function call can "exit"? And if so, maybe (or maybe not, dunno) it would be better to focus on making that work as desired, as opposed to a general purpose finish-frame breakpoint handler. The latter may be sufficiently useful as well of course. At this point I'd just like to understand the main use-case.