Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Kevin Pouget <kevin.pouget@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: [RFC] Python Finish Breakpoints
Date: Thu, 12 May 2011 19:00:00 -0000	[thread overview]
Message-ID: <BANLkTi=Eu-5B4YyhP2rGdQXgXbBN-EmLKA@mail.gmail.com> (raw)
In-Reply-To: <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.


  parent reply	other threads:[~2011-05-12 19:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-09 14:11 Kevin Pouget
2011-05-09 14:31 ` Kevin Pouget
     [not found]   ` <BANLkTikVdqbMqjguTV8ct0TWiBDhHGYtLg@mail.gmail.com>
2011-05-11  7:44     ` Kevin Pouget
2011-05-11 10:31       ` Phil Muldoon
2011-05-11 11:29         ` Kevin Pouget
2011-05-12 10:50         ` Phil Muldoon
2011-05-12 11:29           ` Kevin Pouget
2011-05-12 19:00 ` Doug Evans [this message]
2011-05-13  7:51   ` Phil Muldoon
     [not found]   ` <BANLkTikt2hEUcXkGVH44NaUcwiF1SGdMaw@mail.gmail.com>
2011-05-13  9:04     ` Kevin Pouget
2011-05-16 11:24       ` Kevin Pouget
2011-05-18  8:58         ` Kevin Pouget
2011-05-18 10:16           ` Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=Eu-5B4YyhP2rGdQXgXbBN-EmLKA@mail.gmail.com' \
    --to=dje@google.com \
    --cc=gdb@sourceware.org \
    --cc=kevin.pouget@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox