public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Kevin Pouget <kevin.pouget@gmail.com>
Cc: gdb-patches@sourceware.org, pmuldoon@redhat.com
Subject: Re: [RFC] Python Finish Breakpoints
Date: Thu, 17 Nov 2011 17:48:00 -0000	[thread overview]
Message-ID: <m3ehx6fxnf.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAPftXU+y1YoqT7H6YwFKiqgmxhVSdpPTWQGek899utvPO2bmfw@mail.gmail.com>	(Kevin Pouget's message of "Wed, 9 Nov 2011 15:09:32 +0100")

>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:

Kevin> py-breakpoint.c::gdbpy_should_stop is executed _before_ we have the
Kevin> chance to save the stop_registers, used to compute the return value
Kevin> (in infrun.c::normal_stop).
Kevin> (the problem existed since the beginning, but I never faced it before)

Kevin> I've updated the function infcmd.c::get_return_value to take this
Kevin> situation into account, using the current registers if the
Kevin> 'stop_registers' are not set, based on what is done in
Kevin> infrun.c::normal_stop:

This approach seems reasonable to me but I am not sure whether or not it
is really ok.  Most times I've tried to change infrun, I've been burned.

Kevin> I think that I handle that in the following lines:
Kevin> +  if (except.reason < 0
Kevin> +      || !self_bpfinish->return_type || !self_bpfinish->function_type)

The problem is that Python errors are sticky.  So, if one occurs one
must either pass it upward (having the current function fail), or clear
it somehow.  It isn't ok to ignore them, call other Python functions,
and then later check.

Kevin> I think I wrote a word about that in the previous mail, anyway, my
Kevin> feeling was that I don't want to abort the FinishBreakpoint creation
Kevin> just because of a return value not computable, so I currently nullify
Kevin> these fields and silently disable return value computation. I can't
Kevin> see any straightforward way to notify Python about that,
Kevin> warning/exceptions won't suite ... otherwise, I could expose the
Kevin> return_type to the Python interface, this way, one could check that
Kevin> it's not None and now if GDB will/might be able to compute the return
Kevin> value when the FinishBP is hit

Ok, this makes sense to me.

Tom> bpfinishpy_detect_out_scope_cb still acquires the GIL (via
Tom> ensure_python_env), but should not.

Kevin> I'm not exactly sure what was you concern here, as far as I
Kevin> understand, the GIL was acquired in bpfinishpy_handle_stop, so it
Kevin> should have no effect in detect_out_scope_cb. So I've removed it from
Kevin> detect_out_scope_cb as it was useless.

I think it is inefficient to recursively acquire the GIL.

Kevin> +@defun FinishBreakpoint.__init__ (@r{[}frame@r{]} @r{[}, internal@r{]})
Kevin> +Create a finish breakpoint at the return address of the @code{gdb.Frame}
Kevin> +object @var{frame} (or @code{gdb.selected_frame()} is not provided).  The 

I think it should read something like:

    Create a finish breakpoint at the return address of the @code{gdb.Frame}
    object @var{frame}.  If @var{frame} is not provided, this defaults to
    the newest frame.

I think it is better to default to the newest frame, because the
selected frame is more of a user-interface thing, and I think code
wanting this should explicitly use it.

Kevin> +type is @code{VOID}

I think just @code{void} is better.

Kevin> +  /* If stop_registers where not saved, use the current registers.  */

s/where/were/

Kevin> +  if (cleanup)
Kevin> +    do_cleanups (cleanup);

This is a gdb anti-pattern.  A call to make_cleanup can return NULL in
some scenarios.

It is better to install a null cleanup and then unconditionally call
do_cleanups.

Kevin> +  /* Default to gdb.selected_frame if necessary.  */
Kevin> +  if (!frame_obj)
Kevin> +    frame_obj = gdbpy_selected_frame (NULL, NULL);

gdbpy_newest_frame

I don't think there is a decref for the frame_obj along this path.

Kevin> +          PyErr_SetString (PyExc_ValueError,
Kevin> +            _("\"FinishBreakpoint\" not meaningful in the outermost frame."));
       
Indentation.

Kevin> +          PyErr_SetString (PyExc_ValueError,
Kevin> +                   _("\"FinishBreakpoint\" cannot be set on a dummy frame."));

Indentation.

Kevin> +            PyErr_SetString (PyExc_ValueError,
Kevin> +                                     _("Invalid ID for the `frame' object."));

Indentation.

Kevin> +              /* Remember only non-VOID return types.  */
Kevin> +              if (TYPE_CODE (ret_type) != TYPE_CODE_VOID)
Kevin> +                {
Kevin> +                  self_bpfinish->return_type = type_to_type_object (ret_type);
Kevin> +                  self_bpfinish->function_type =
Kevin> +                      type_to_type_object (SYMBOL_TYPE (function));

As discussed above, you need to check for errors immediately after each
call, and DTRT.  You can ignore them with PyErr_Clear.

Kevin> +static void
Kevin> +bpfinishpy_out_of_scope (struct finish_breakpoint_object *bpfinish_obj)
Kevin> +{
[...]
Kevin> +  TRY_CATCH (except, RETURN_MASK_ALL)
Kevin> +    {
Kevin> +      delete_breakpoint (bpfinish_obj->py_bp.bp);
Kevin> +    }
Kevin> +  if (except.reason < 0)
Kevin> +    {
Kevin> +      gdbpy_convert_exception (except);
Kevin> +      gdbpy_print_stack ();
Kevin> +    }

I probably asked you to add this, but if bpfinishpy_out_of_scope can
only be called in one spot:

Kevin> +          TRY_CATCH (except, RETURN_MASK_ALL)
Kevin> +            {
Kevin> +              if (b->pspace == current_inferior ()->pspace
Kevin> +                 && (!target_has_registers
Kevin> +                     || frame_find_by_id (b->frame_id) == NULL))
Kevin> +              {
Kevin> +                bpfinishpy_out_of_scope (finish_bp);
Kevin> +              }
Kevin> +            }
Kevin> +          if (except.reason < 0)
Kevin> +            {
Kevin> +              gdbpy_convert_exception (except);
Kevin> +              gdbpy_print_stack ();
Kevin> +            }

... then the TRY_CATCH in bpfinishpy_out_of_scope is not needed.

Kevin> +  struct cleanup *cleanup = ensure_python_env (target_gdbarch,
Kevin> +      current_language);

Indentation.

Tom

  parent reply	other threads:[~2011-11-17 17:48 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BANLkTim+YH64zkWvdz2_kVUUj=AJ7v4LKw@mail.gmail.com>
     [not found] ` <BANLkTi=gtHzWzXOJzB+a19=jkfk1hGwQBg@mail.gmail.com>
     [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:38           ` Kevin Pouget
2011-05-12 10:50         ` Phil Muldoon
2011-05-12 11:29           ` Kevin Pouget
     [not found] ` <BANLkTi=Eu-5B4YyhP2rGdQXgXbBN-EmLKA@mail.gmail.com>
     [not found]   ` <BANLkTikt2hEUcXkGVH44NaUcwiF1SGdMaw@mail.gmail.com>
     [not found]     ` <BANLkTi=UpgogckTD5MZsW+PC5d2F8X-+jA@mail.gmail.com>
     [not found]       ` <BANLkTi==bj50mZgFKq_qA-+3-2CQA3tBVw@mail.gmail.com>
     [not found]         ` <BANLkTimmYEmvKT_984jYEVZnA5RGFpEgNw@mail.gmail.com>
2011-05-19 16:21           ` Tom Tromey
2011-05-24 12:51             ` Kevin Pouget
2011-05-27 20:30               ` Tom Tromey
2011-05-30  9:29                 ` Kevin Pouget
2011-10-13 14:34                   ` Kevin Pouget
2011-10-20 20:12                     ` Tom Tromey
2011-10-20 20:58                   ` Tom Tromey
2011-10-21  8:15                     ` Kevin Pouget
2011-10-24 11:43                       ` Kevin Pouget
2011-10-24 13:20                         ` Eli Zaretskii
2011-10-24 14:30                           ` Kevin Pouget
2011-10-24 17:14                             ` Eli Zaretskii
2011-10-24 15:31                         ` Kevin Pouget
2011-10-24 16:27                           ` Phil Muldoon
2011-10-25 11:05                             ` Kevin Pouget
2011-10-25 11:37                               ` Phil Muldoon
2011-10-25 12:22                                 ` Kevin Pouget
2011-10-28  8:33                                   ` Kevin Pouget
2011-10-28 20:51                                     ` Tom Tromey
2011-11-02 14:44                                       ` Kevin Pouget
2011-11-04 14:25                                         ` Kevin Pouget
2011-11-04 21:04                                           ` Tom Tromey
2011-11-09 14:10                                             ` Kevin Pouget
2011-11-16 10:53                                               ` Kevin Pouget
2011-11-17 17:49                                                 ` Tom Tromey
2011-11-17 17:48                                               ` Tom Tromey [this message]
     [not found]                                                 ` <CAPftXUJwtGJhqFyfX6LVK87QH2xeLkvv5kx=yaEnYJMv0YR_rw@mail.gmail.com>
2011-11-24  8:27                                                   ` Kevin Pouget
2011-11-30 16:02                                                     ` Kevin Pouget
2011-12-02 21:49                                                       ` Tom Tromey
2011-12-05  9:29                                                         ` Kevin Pouget
2011-12-06 21:18                                                           ` Tom Tromey
2011-12-07 13:35                                                             ` Kevin Pouget
2011-12-08 15:30                                                               ` Tom Tromey
2011-12-08 16:10                                                                 ` Kevin Pouget
2011-12-08 18:08                                                                   ` Kevin Pouget
2011-12-09  9:53                                                                     ` Kevin Pouget
2011-12-18 19:22                                                                       ` Kevin Pouget
2011-12-20 20:55                                                                       ` Tom Tromey
2011-12-20 20:58                                                                         ` Kevin Pouget
2011-12-21  7:16                                                                           ` Joel Brobecker
2011-12-21 17:13                                                                             ` Tom Tromey
     [not found]                                                                               ` <CAPftXUKXh9ekZ2kiwQ=5zbrjst+9VH9-eZk8h+Z-9SpQ1WqdLw@mail.gmail.com>
     [not found]                                                                                 ` <CAPftXULQFggY3Nz2byC0fMZA1sg4Nymp3hAhe8aSuLNG4cauFg@mail.gmail.com>
     [not found]                                                                                   ` <CAPftXUJALHd=-fajVwgowqfCDfXO6JMxSkorWD6CQArsg-PedQ@mail.gmail.com>
     [not found]                                                                                     ` <CAPftXULKC8gp3L87+PZEF3dj3crv9bh-uzZpRiYKjqEw_xyptQ@mail.gmail.com>
2011-12-27  4:18                                                                                       ` Joel Brobecker
2011-12-27  9:40                                                                                         ` Kevin Pouget
2011-12-27 12:22                                                                                           ` Joel Brobecker
2011-12-27  9:34                                                                                       ` Kevin Pouget
2011-12-24 23:56                                                                           ` [patch] Fix gdb.python/py-finish-breakpoint.exp new FAIL on x86_64-m32 [Re: [RFC] Python Finish Breakpoints] Jan Kratochvil
2011-12-27 11:13                                                                             ` Kevin Pouget
2011-12-27 21:39                                                                               ` [commit] " Jan Kratochvil
2012-01-04 17:45                                                                             ` Ulrich Weigand
2012-01-04 17:58                                                                               ` [commit 7.4] " Jan Kratochvil
2012-01-04 18:10                                                                                 ` Ulrich Weigand
2011-12-26 11:28                                                                           ` [patch] Fix remote.c crash on gdbserver close (+fix py-finish-breakpoint.exp for gdbserver) " Jan Kratochvil
2011-12-27 23:30                                                                             ` [patch] Fix remote.c crash on gdbserver close (+fix py-finish-breakpoint.exp for gdbserver) [rediff] Jan Kratochvil
2012-01-02 17:57                                                                               ` Tom Tromey
2012-01-02 19:49                                                                               ` Pedro Alves
2012-01-19 16:24                                                                                 ` Call target_close after unpushing, not before (was: Re: [patch] Fix remote.c crash on gdbserver close (+fix py-finish-breakpoint.exp for gdbserver)) Pedro Alves
2012-01-19 16:27                                                                                   ` Jan Kratochvil
2012-01-19 16:37                                                                                     ` Call target_close after unpushing, not before Pedro Alves
2012-01-19 16:53                                                                                     ` [commit] Re: Call target_close after unpushing, not before (was: Re: [patch] Fix remote.c crash on gdbserver close (+fix py-finish-breakpoint.exp for gdbserver)) Jan Kratochvil
2012-01-04 14:49                                                                       ` [RFC] Python Finish Breakpoints Ulrich Weigand
2012-01-04 15:24                                                                         ` Kevin Pouget
2012-01-04 16:29                                                                           ` Ulrich Weigand
2012-01-04 16:42                                                                           ` Tom Tromey
2012-01-04 16:40                                                                         ` Tom Tromey
2012-01-04 17:13                                                                           ` Ulrich Weigand
2012-01-09  9:21                                                                             ` Kevin Pouget
2012-01-27 17:01                                                                               ` Kevin Pouget
2011-10-28 19:26                                   ` Tom Tromey

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=m3ehx6fxnf.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevin.pouget@gmail.com \
    --cc=pmuldoon@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).