From: Pedro Alves <palves@redhat.com>
To: "Gustavo, Luis" <luis_gustavo@mentor.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [rfc target-side break conditions 3/5 v2] GDB-side changes
Date: Thu, 09 Feb 2012 12:56:00 -0000 [thread overview]
Message-ID: <4F33C27E.2090304@redhat.com> (raw)
In-Reply-To: <4F32E167.6050600@mentor.com>
On 02/08/2012 08:56 PM, Luis Gustavo wrote:
>> I'm confused. How does this (and all similar places) address the issued I
>> pointed out before? If you're passing one to update_global_location_list
>> when deleting a breakpoint, you're pretty much defeating the whole
>> purpose of the update_global_location_list's argument in the first place.
>>
>
> Updates will only take place when the user explicitly removes/disables a breakpoint. Functions that are deleting breakpoints (like remove_thread_event_breakpoints) won't cause insertion of any breakpoints since they go through the "delete_breakpoint" path, not the delete_breakpoint_with_update one.
Ah, got it now. Thanks. But please:
> + structures. If UPDATE is true, proceed to update the list of
> + locations, otherwise don't update it. */
>
> -void
> -delete_breakpoint (struct breakpoint *bpt)
> +static void
> +delete_breakpoint_1 (struct breakpoint *bpt, int update)
"update" here is quite confusing, because that's not what is happening. Or at
least, update is so overloaded that I'm not understanding it the way you are.
The list of locations is still updated/regenerated, and we do delete locations
from the target, but, we don't allow new insertions. So, could we
s/update/somethingelse/ please? Even pointing at update_global_location_list's
description of its parameter would be good.
Or maybe, I just had an idea --- I wonder if we made update_global_location_list
still re-insert _only_ the _already inserted_ locations when the
condition changes, then we'd be good. That is, something like:
update_global_location_list:
...
- if (breakpoints_always_inserted_mode () && should_insert
- && (have_live_inferiors ()
- || (gdbarch_has_global_breakpoints (target_gdbarch))))
- insert_breakpoint_locations ();
+ if (breakpoints_always_inserted_mode ()
+ && (have_live_inferiors ()
+ || (gdbarch_has_global_breakpoints (target_gdbarch))))
+ {
+ if (should_insert)
+ insert_breakpoint_locations ();
+ else
+ update_inserted_breakpoint_locations ();
+ }
The problem is that a delete_breakpoint would trigger insertions of all
_other_ breakpoints. But if we're allow "reinserting" breakpoints that
are _already_ inserted, I think we're fine.
> Is disabling breakpoints also something we would like to do without triggering insertions? If so, i'm inclined to go with the same solution as for deleting user breakpoints.
Maybe, not sure. Better be safe, I think.
It'd be nice to come up with a better way to solve the initial problem that
led to update_global_location_list having an argument in the first place. :-/
--
Pedro Alves
next prev parent reply other threads:[~2012-02-09 12:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 20:34 Luis Gustavo
2012-02-06 20:27 ` Tom Tromey
2012-02-07 11:16 ` Luis Gustavo
2012-02-08 19:33 ` Pedro Alves
2012-02-08 20:56 ` Luis Gustavo
2012-02-09 12:56 ` Pedro Alves [this message]
2012-02-22 15:29 ` Luis Gustavo
2012-02-23 17:38 ` Pedro Alves
2012-02-24 12:20 ` Luis Gustavo
2012-02-24 13:01 ` Pedro Alves
2012-02-24 13:04 ` Luis Gustavo
2012-02-09 13:00 ` Pedro Alves
2012-02-07 19:13 ` Pedro Alves
2012-02-07 19:26 ` Stan Shebs
2012-02-07 22:08 ` Stan Shebs
2012-02-08 23:13 ` Luis Gustavo
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=4F33C27E.2090304@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis_gustavo@mentor.com \
--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