From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Keep breakpoints always inserted.
Date: Mon, 10 Mar 2008 21:09:00 -0000 [thread overview]
Message-ID: <20080310210844.GB14908@caradoc.them.org> (raw)
In-Reply-To: <200802281717.14766.vladimir@codesourcery.com>
On Thu, Feb 28, 2008 at 05:17:13PM +0300, Vladimir Prus wrote:
>
> This is hopefully final revision of my patch to keep
> breakpoints always inserted, which is needed to support
> non-stop mode. A new variable 'breakpoint always-inserted'
> is introduced that enables this mode. When enabled,
> breakpoints are inserted into target immediately when created,
> and they are not removed when we stop.
>
> Compared to the previous version of this patch:
> - The always-inserted mode is actually configurable
> - In always-inserted mode, breakpoints are removed
> from target on detach/disconnect.
>
> OK?
This patch is OK, if you will add the missing pieces: a NEWS entry and
documentation for the new command, and a testcase that enables
always-inserted and verifies that it isn't a brick.
> +static void
> +insert_breakpoint_locations (void);
No newline before function name in prototypes.
> +/* If 1, gdb will keep breakpoints inserted even as
> + inferior is stopped, and immediately insert any new
> + breakoints.
> + If 0, gdb will insert breakpoints into inferior only
> + when rusuming it, and will remove breakpoints
> + upon stop. */
Typos: breakoints, rusuming. I've noticed your comments always
wrap early, around column 60 instead of 72 or 79; is there any
particular reason for that? It looks awkward when other comments in
the same file wrap further over.
> + /* Identify bp_location instances that are not
> + longer present in the new list, and therefore should
no longer present
> + /* If this location is not longer present, and
ditto
> + inserted, look if there's maybe new location
a new location
> + at the same address. If so, mark that one
> + inserted, and don't remove this one.
> +
> + This is needed so that we don't have a window
> + where a breakpoint at certian location is not
certain
> + /* For the sake of should_insert_location. The
> + call the check_duplicates will fix up this later. */
the call to
> + if (loc->inserted && !found_object && !found_address)
> {
> - tmp = &((*tmp)->global_next);
> + /* FIXME? Handle error? */
> + remove_breakpoint (loc, mark_uninserted);
> }
Can you take care of this FIXME?
> +int breakpoints_always_inserted_mode ()
> +{
> + return always_inserted_mode;
> +}
(void)
> +
> \f
> /* This help string is used for the break, hbreak, tbreak and thbreak commands.
> It is defined as a macro to prevent duplication.
> @@ -8341,6 +8393,19 @@ a warning will be emitted for such breakpoints."),
> show_automatic_hardware_breakpoints,
> &breakpoint_set_cmdlist,
> &breakpoint_show_cmdlist);
> +
> + add_setshow_boolean_cmd ("always-inserted", class_support,
> + &always_inserted_mode, _("\
> +Set mode for inserting breakpoints."), _("\
> +Show mode for inserting breakpoints."), _("\
> +When this mode is off (which is default), breakpoints are inserted in\n\
which is the default
> +inferior when it is resumed, and removed when execution stops. When this\n\
> +mode is on, breakpoints are inserted immediately and removed only when\n\
> +the user deletes the breakpoint."),
> +extern int breakpoints_always_inserted_mode ();
(void)
> @@ -1350,10 +1358,6 @@ handle_inferior_event (struct execution_control_state *ecs)
> established. */
> if (stop_soon == NO_STOP_QUIETLY)
> {
> - /* Remove breakpoints, SOLIB_ADD might adjust
> - breakpoint addresses via breakpoint_re_set. */
> - remove_breakpoints ();
> -
> /* Check for any newly added shared libraries if we're
> supposed to be adding them automatically. Switch
> terminal for any messages produced by
> @@ -1393,9 +1397,6 @@ handle_inferior_event (struct execution_control_state *ecs)
>
> /* NOTE drow/2007-05-11: This might be a good place to check
> for "catch load". */
> -
> - /* Reinsert breakpoints and continue. */
> - insert_breakpoints ();
> }
>
> /* If we are skipping through a shell, or through shared library
This does the right thing even with breakpoints not always inserted,
right?
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-03-10 21:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 14:18 Vladimir Prus
2008-03-10 21:09 ` Daniel Jacobowitz [this message]
2008-03-14 20:22 ` Vladimir Prus
2008-03-15 10:13 ` Vladimir Prus
2008-03-15 15:10 ` Eli Zaretskii
2008-04-02 13:02 ` Vladimir Prus
2008-04-02 18:18 ` Eli Zaretskii
2008-03-17 22:21 ` Daniel Jacobowitz
2008-03-18 4:15 ` Eli Zaretskii
2008-03-18 6:06 ` Vladimir Prus
2008-04-03 18:10 ` Vladimir Prus
2008-04-07 15:32 ` Daniel Jacobowitz
2008-04-09 23:45 ` Vladimir Prus
2008-04-10 8:16 ` Luis Machado
2008-04-17 16:50 ` Daniel Jacobowitz
2008-04-23 21:18 ` Pedro Alves
2008-04-23 21:24 ` Daniel Jacobowitz
2008-04-24 11:22 ` Vladimir Prus
2008-04-24 12:10 ` Vladimir Prus
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=20080310210844.GB14908@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@codesourcery.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