This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] Python Finish Breakpoints
- From: Doug Evans <dje at google dot com>
- To: Kevin Pouget <kevin dot pouget at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 12 May 2011 12:00:11 -0700
- Subject: Re: [RFC] Python Finish Breakpoints
- References: <BANLkTim+YH64zkWvdz2_kVUUj=AJ7v4LKw@mail.gmail.com>
Hi. re:
On Mon, May 9, 2011 at 7:10 AM, Kevin Pouget <kevin.pouget@gmail.com> 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)
> {
> ? *a += 5;
> ? sleep(a);
> ? 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.