Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Pouget <kevin.pouget@gmail.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Python Finish Breakpoints
Date: Thu, 24 Nov 2011 08:27:00 -0000	[thread overview]
Message-ID: <CAPftXUKD3Oy_jbZaUFDTbGt3w9XqrSq5O2d_cv5ZGrUyeREx7g@mail.gmail.com> (raw)
In-Reply-To: <CAPftXUJwtGJhqFyfX6LVK87QH2xeLkvv5kx=yaEnYJMv0YR_rw@mail.gmail.com>

On Thu, Nov 17, 2011 at 6:48 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> >>>>> "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.

I'm not sure what to do here,
I don't change the value of the global variable "stop_registers" so
if shouldn't affect more than my code,
but it also depends of the side effects of
> regcache_dup (get_current_regcache ())
which is now triggered 'slightly' before when it used to be ...

> 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> +              /* 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.

ok, I didn't know this point, so I've rewritten this to
unconditionally clear the Py exception after these two calls, and then
test against NULL as before.

> 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.

right, the doc doesn't say anything about the efficiency of GIL
acquisition, so let's
assume you're right!

> 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).
>
> 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.

ok for the sentence construction,

> 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.

My thought when I chose to use 'selected_frame' was to match the
behavior of the CLI finish command. When you type it, you finish the
'selected' frame, and not the newest one.

In my use-cases, I always have gdb.selected_frame == gdb.newest_frame,
so I don't have a strong preference. I've switch the code/doc to
newest_frame.

> Kevin> +type is @code{VOID}
>
> I think just @code{void} is better.

sure

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

fixed

> 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.

ok, didn't know it either, fixed with the null cleanup

> 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.

I've changed it to:

 if (!frame_obj)
   frame_obj = gdbpy_newest_frame (NULL, NULL);
 else
   Py_INCREF (frame_obj);

 frame = frame_object_to_frame_info (frame_obj);
 Py_DECREF (frame_obj);

which looks clearer to me than setting a flag, or testing the kwargs
for the "frame" keyword

> Kevin> +          PyErr_SetString (PyExc_ValueError,
> Kevin> +            _("\"FinishBreakpoint\" not meaningful in the outermost frame."));
>
> 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.

These 3 lines where right-justified to column 79, I've split them.

> 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.

right

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

fixed


There is no regression against the current tree (2011-11-18)


Thanks,

Kevin

2011-11-18  Kevin Pouget  <kevin.pouget@st.com>

       Introduce gdb.FinishBreakpoint in Python

       * Makefile.in (SUBDIR_PYTHON_OBS): Add py-finishbreakpoint.o.
       (SUBDIR_PYTHON_SRCS): Add python/py-finishbreakpoint.c.
       Add build rule for this file.
       * infcmd.c (print_return_value): Split to create get_return_value.
       (get_return_value): New function based on print_return_value. Handle
       case where stop_registers are not set.
       * inferior.h (get_return_value): New prototype.
       * python/py-breakpoint.c (bppy_pending_object): Make non-static.
       (gdbpy_breakpoint_created): Set is_py_finish_bp is necessary.
       (struct breakpoint_object): Move to python-internal.h
       (BPPY_REQUIRE_VALID): Likewise.
       (BPPY_SET_REQUIRE_VALID): Likewise.
       (gdbpy_breakpoint_created): Initialize is_finish_bp.
       (gdbpy_should_stop): Add  pre/post hooks before/after calling stop
       method.
       * python/python-internal.h (breakpoint_object_type): Add as extern.
       (bppy_pending_object): Likewise.
       (typedef struct breakpoint_object) Removed.
       (struct breakpoint_object): Moved from py-breakpoint.c.
       Add field is_finish_bp.
       (BPPY_REQUIRE_VALID): Moved from py-breakpoint.c.
       (BPPY_SET_REQUIRE_VALID): Likewise.
       (frame_object_to_frame_info): New prototype.
       (gdbpy_initialize_finishbreakpoints): New prototype.
       (bpfinishpy_is_finish_bp): Likewise.
       (bpfinishpy_pre_stop_hook): Likewise.
       (bpfinishpy_post_stop_hook): Likewise.
       * python/py-finishbreakpoint.c: New file.
       * python/py-frame.c(frame_object_to_frame_info): Make non-static and
       accept PyObject instead of frame_object.
       (frapy_is_valid): Don't cast to frame_object.
       (frapy_name): Likewise.
       (frapy_type): Likewise.
       (frapy_unwind_stop_reason): Likewise.
       (frapy_pc): Likewise.
       (frapy_block): Likewise.
       (frapy_function): Likewise.
       (frapy_older): Likewise.
       (frapy_newer): Likewise.
       (frapy_find_sal): Likewise.
       (frapy_read_var): Likewise.
       (frapy_select): Likewise.
       * python/python.c (gdbpy_is_stopped_at_finish_bp): New noop function.
       (_initialize_python): Add gdbpy_initialize_finishbreakpoints.
       * python/python.h: Include breakpoint.h
       (gdbpy_is_stopped_at_finish_bp): New prototype.

doc/
       * gdb.texinfo (Finish Breakpoints in Python): New subsection.
       (Python API): Add menu entry for Finish Breakpoints.

testsuite/
       * gdb.python/py-breakpoint.exp (mult_line): Define and use variable
       instead of line number.
       * gdb.python/py-finish-breakpoint.c: New file.
       * gdb.python/py-finish-breakpoint.exp: New file.
       * gdb.python/py-finish-breakpoint.py: New file.
       * gdb.python/py-finish-breakpoint2.cc: New file.
       * gdb.python/py-finish-breakpoint2.exp: New file.
       * gdb.python/py-finish-breakpoint2.py: New file.


  parent reply	other threads:[~2011-11-24  8:27 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
     [not found]                                                 ` <CAPftXUJwtGJhqFyfX6LVK87QH2xeLkvv5kx=yaEnYJMv0YR_rw@mail.gmail.com>
2011-11-24  8:27                                                   ` Kevin Pouget [this message]
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=CAPftXUKD3Oy_jbZaUFDTbGt3w9XqrSq5O2d_cv5ZGrUyeREx7g@mail.gmail.com \
    --to=kevin.pouget@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@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